Spawn a process in Labview 7.1

[H View Labs]

Along the same lines of how and when compilation occurs:

I tried to use report generation VIs on a couple of projects. It didn't work and NI support advised to do Ctrl-Shift-Run (on Windows). Then everything worked! If LV compiles every time it is needed, then why did I need Ctrl-Shift-Run to make report generation VIs work? What is different (except marking all VIs as modified) between just Run and Ctrl-Shift-Run? I don't think Ctrl-Shift-Run is really documented anywhere. Maybe this is worth a separate thread.

Stanislav Rumega, CLA

[rolfk]

The issue at hand with the Report Generation Toolkit are that it is based on Active X. Active X is an external technology and LabVIEW has to interface to it over the means made available by Microsoft. A lot of things in Active X are supposed to be automatically done, such as version conversions and such things. However  LabVIEW has in order to interface to an Active X control to make a lot of special decisions.  One of them is to adapt the calling of methods with optional parameters to be one right. Those optional parameters however can and often do change between versions. LabVIEW does not recompile a VI containing Active X if it was created on the same platform and LabVIEW version, but recompilation is sometimes necessary for adjustement of the optional parameters of methods to the current installed Active X control on the machine.

So recompiling can sometimes fix things LabVIEW would otherwise run into an error, while LabVIEW thinks that recompilation is not currently necessary.  These situations are almost always related to external things such as Active X or Call Library Nodes, where LabVIEW doesn't have full control over what might have changed between last saving of a VI and loading it.

So pressing Ctrl-Shift-Run will recompile any and all VIs currently in memory. Ctrl-Run will only compile the current VI. I'm pretty sure these shortcuts are documented in the manual and also on the small command overview leaflet which at least in LabVIEW 6.x was shipped in the software box.

Rolf Kalbermatter

[Ben]

Hi Philip,

I would also like to see that paper. My understanding of this topic iss full of holes and I have to resort to experimenting to make sure I can do what I want.

I used VIT's with success in built apps with no problems. I was suprised to find out that I the VIT's in LV 7.x could do "VI Server>>> call by references" where the target was a VI servered from a LV 6.1 exe. This I thought would have caused problems. (Sometime the hardest questions to answer are along the lines of "Why did that work?")

While you are at it, see if you can give us some insight into how the "preapre for re-entrant execution" property is capable of pulling that stunt off at run-time.

Ben

PS Don't you just love Rolf steeping in?

[JeanPierre]

Ben,

I have not much experienced with that but the protocol used by VI Servers seem to be to some extent compatible form one version of LabVIEW to the next. To call a VI by reference, the VI Server receives the data through a TCP connexion execute the VI and resends the data back to the caller application. LV7.x can recognize the version on the protocol and adapt the communication if necessary.

Prepare for reentrant execution: before this option was introduced, opening a non-typed reference  (to Run the VI, not call it by reference) to a reentrant VI has has the same effect as to a non-reentrant VI. The VI was instanciated only once and any other references opened to the VI was to the same instance. We absolutely had to use VIT to get mutiple instances on a reentrant VI (in which case reentrancy was irrelevant). With the prepare for reentrant run option, it is now possible to open multiple non-typed references to a reentrant VI and get multiple running instances of the VI. Now the VIT is required only if you need the user to interact with the front panel of all instances. However, I think that you laready know all that... what is exactly the stunt that needs some insight? The VI has to be set reentrant at edit time for the reentrant option to work; that is not the VI server that make it reentrant.

[Ben]

JP wrote

"

I have not much experienced with that but the protocol used by VI Servers seem to be to some extent compatible form one version of LabVIEW to the next. To call a VI by reference, the VI Server receives the data through a TCP connexion execute the VI and resends the data back to the caller application. LV7.x can recognize the version on the protocol and adapt the communication if necessary.

"

And this impresses me big time! At the same time I would like to know more about this aspect.

JP continued

"
Prepare for reentrant execution: before this option was introduced, opening a non-typed reference  (to Run the VI, not call it by reference) to a reentrant VI has has the same effect as to a non-reentrant VI. The VI was instanciated only once and any other references opened to the VI was to the same instance. We absolutely had to use VIT to get mutiple instances on a reentrant VI (in which case reentrancy was irrelevant).

"

I did not know this. I can not say that I have ever developed any code that used that capability. I always resorted to the VIT method not thinking that there was another way of doing it.

JP closes with

"

With the prepare for reentrant run option, it is now possible to open multiple non-typed references to a reentrant VI and get multiple running instances of the VI. Now the VIT is required only if you need the user to interact with the front panel of all instances. However, I think that you laready know all that... what is exactly the stunt that needs some insight? The VI has to be set reentrant at edit time for the reentrant option to work; that is not the VI server that make it reentrant.

"

That was the part I had had a very difficult part getting my head around. How does VI server make a Vi re-entrant? If the VI server is not modifying the target VI then "prepare for re-entrant..." must just affect the way it is instansiated...? What all is involved in the process of instasiating a VI? When a VI is not re-entrantrant there appear to be semahopres protecting the code and preventing simultaneous execution. The code also has to be compiled in a from that allows it to adapt from using a set of staic local varables in non-reentrant to unique copies for each. VI Server has t be able to "touch" this stuff at run time...? All of this makes my head spin!

I would like to learn more.

Ben

Message Edited by Ben on 07-17-2005 11:43 AM

[JeanPierre]

Ben,

In LabVIEW 4.1, before the VI server,  there was VI Controls VIs that allowed to dynamically load,run and call VIs by VI name/path. In the example folder, the library victltcp.llb shows a tcp remote implementation of the control VIs, as a precursor of the TCP VI Server we know. It shows some insight of how the things work under the hood.

See the attached diagram. On the client side, VI path, inputs and required outputs are flattened to a string and sent to the server over a TCP connection. On the server side, data is unflattened and the VI Control VIs are invoked to dynamically call the VI with the inputs. The outputs are flattened and returned to the caller. I have opened this LV4.1 VI  with  LV7.1: see the 4.x on flatten and unflatten nodes. That tells LabVIEW 7.1 to use 4.x data format so in principle, this VI in 7.1 could call a 4.x run server.

I have nodirect insight on the guts of LabVIEW VI Server but the things must work very similar to this. If the client connects to a remote VI Server, it has a way to know which server version is running and adapt its call to be backward compatible to previous versions.

These questions about VI Server and VI instanciation, you should ask them in the LabVIEW Developpers thread. I can only give you pointers about my own mental representation of how LabVIEW works but it is not first hand stuff.

[rolfk]

While the principle is the same, it is a lot more powerful in LabVIEW 5 than it ever could have been in LabVIEW 4. The protocol is also not quite the same altough the basic principle of course doesn't change much as there are not to many options to implement such a functionality.

The VI server does use versioning in its protocol. As far as I could find out is the version negotiated at connection establishment. There are limitations about VI server compatibilty. The protocol in 7.0 has been extended to support new features and either a 7.0 server can be contacted by a 6.x client or vice versa but I'm not sure about which. The actual details are described in the 7.0 upgrade notes.

While I have researched the protocol in LabVIEW 6 and even got some communication going from a VI library to a VI server it is not to to easy and there are lots of undefined details. I also think that there is little use in going this path further since the protocol can change at every version and also does to some extend.

Rolf Kalbermatter

Message Edited by rolfk on 07-18-2005 04:29 PM

[Kevin_Price]

Sorry for hijacking the thread but I've got some questions related to an app I'm working on where I'd like to spawn multiple autonomous processes that I can query for status.  It's essentially going to be N instances of the same process control algorithm using a Fieldpoint 2010 RT controller and a bunch of I/O modules.

My first go was to create the code as a .vit template.  I created a "launcher/queryer" vi that is called by my main app with wires passing in.  It in turn uses VI server to copy all its control values down to the template instance before running it using the 'Run VI' invoke node (without waiting for completion).  This generally worked well, but occasionally the instance would be launched using the launcher's default values rather the values I  wired in.  By adding a short delay between writing the control values and running the vi, the problem almost disappeared.  What fully worked was to make sure the launcher vi's front panel was open before copying its control values.

Ok, so this worked in Windows.  Each time I a process was instantiated, its front panel was opened and minimized so I could easily mess with the process control variables live.  Life was good.  (Note: in this architecture, the "launcher/queryer" is an action engine with actions such as Launch process, Stop process, Query process, etc.  All inputs needed by the process are wired into the launcher's controls.  All outputs and status are indicator wires.  The "launcher" is really just an interface into an otherwise autonomous process.)

Next step was to target the Fieldpoint RT controller.  No go.  RT doesn't support templates.  So I decided to try to make my own "poor man's" template.  On each attempted launch, I would use the file primitives to copy my master vi giving it a unique (iteration #) name.  (These are deleted when the program shuts down.  They're also deleted if they already exist when its time to make the copy).  Once again I used the VI server calls to copy the control values before running.

Again, this worked just fine in Windows.  When I targeted the Fieldpoint RT controller, it still worked, but got annoying.  It turned out that every file copy operation took several seconds because the FP controller uses some sort of flash memory as a virtual hard drive.  So my initialization sequence started taking about a minute to run.   Also, the VI server calls to copy indicator values up from the spawned process to the "launcher/queryer" vi proved to be pretty slow - up to a couple hundred msec per process.

So then comes a problem.  I wanted to make the master vi Reentrant for the final RT app to avoid all the time spent on disk copying with my pseudo-templates.   But can I write input values down to a specific instance using the "Set Control Value" VI server call?   My first attempt didn't seem to work.  Would any such control values need to be assigned to connector pane terminals even though I never call the vi using wiring?  I'm not done trying yet, but my experience with templates seemed to require the front panel open to make sure the control values "took hold".  This option isn't really relevant with a reentrant vi, is it?  Is my approach doomed?

If so, then the next idea would be to borrow from the RT Comm Wizard and pass control and indicator values down and up using a set of RTFIFO's.  The control values identify the specific FP IO to be used by each control process.  However, I don't know how to get a specific reentrant instance to bind to a specific RTFIFO.   If I launch a process controller this way (run a reentrant vi using "Run VI" invoke node), how do I inform it that it needs to maintain pressures 5 and 6 by controlling valve 2?   I can't wire to it.  It doesn't appear that using VI server to Set Control values will work.  There must be some way, right? 

-Kevin P.

[JeanPierre]

I doubt that you can pass data to a prepared for reentrant run VI using controls value since the many instances share the same FP. That could work but the control values are not "protected" against changes by  other parallel running code between the time you set the values and the time the instance reads these values. This could occur for example if in a loop you open instances, set contols values and run VI: the first instance could read control values after  they've already been modified in the second or third iteration of the loop.
 
You should communicate with another mean with the VI, using for example a named queue or a notifier.

Message Edité par Jean-Pierre Drolet le 07-19-2005 01:41 PM

[Kevin_Price]

Jean-Pierre,

Thanks for the tip -- I'll probably still try some things to be sure, but it doesn't sound promising. I'm still a bit stuck though on how to connect a specific reentrant instance with a specific named queue / RTFIFO. Let me describe an example to try to be more clear.

Let's say there are 3 valve-control processes for me to launch and run simultaneously. So in a loop I'm going to open and run the same reentrant vi 3 times. However each of the 3 instances must monitor and control its own unique Fieldpoint I/O channels. The launcher needs to tell each reentrant instance which channels to "own". 

Now, let's suppose I write all these input parameters to 3 uniquely named RTFIFO's, and also prepare 3 more uniquely named RTFIFO's from which to read back status information.  Then I invoke "Run VI" to start the reentrant instances.  Each instance will have to attach itself to 1 input and 1 output RTFIFO.  The "launcher" will need to know which RTFIFO's are attached to which reentrant instance (uniquely id'ed by their VI Reference). 

Hmmm, maybe I could make 2 more queues that hold the unique RTFIFO names, 1 for inputs and 1 for outputs.  Then each reentrant instance would pull a name from the queue of of input names, retrieve its RTFIFO inputs, pull a name from the queue of output names, push some RTFIFO outputs, then go into its real main loop.  The launcher that just invoked "Run VI" would then query the RTFIFO's until it found out which one had some data in it.  Then it could map the VI Reference for that reentrant instance to the correct RTFIFO's.  Then it would continue ahead to launch the next reentrant instance.

For this method to work, the name of the queues holding the names of the RTFIFO's would need to be known by both the launcher and the reentrant control code.  Either it could be hard-coded in both, or preferably they could both query it from an LV2 global.  So now maybe I've talked my way into a solution, I think, but it seems more complicated than I expected.  Any ideas on a better way?  I can't shake the suspicion that there's probably a much more straightforward solution.  This is starting to feel like too much of a hack...

-Kevin P.