Tore, If you are running on an RT Target, then the reentrant approach is better than the template technique, IMO. The reason is because of a "catch 22" -- you cannot create an instance of a template while the template is in memory; but, the template must be in memory in order to be transferred to the RT target when running in development mode (while targeting the RT system). In order to include a template into the build you would have to add it explicitly as a dynamic VI --> since it cannot be in the application hierarchy --> since you can't have it in memory when an instance is created at run-time. So, in conclusion, when spawning multiple instances of non-GUI processes, I highly recommend the reentrant VI approach in conjunction with the static VI reference to insure that the process VI is included in the application hierarchy. In general, most of my RT/embedded apps have been "headless" (set to run automatically at RT system startup time) and use TCP/IP to serve functionality to high-level GUIs. Since the server supports multiple simultaneous clients, this allows multiple instances of the same GUIs to be run concurrently.
-Jim > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tore Johnsen > Sent: Thursday, May 27, 2004 1:32 PM > To: [EMAIL PROTECTED] > Subject: Re: GOOP and spawning VIs on FieldPoint RT controller > > Alex, Jim: > > Thanks for your help. Exactly what I needed. > > Yep, I use the template technique and pass data to the > spawned VIs using the "Set Control Value" method prior to > running them. In the past (for non time-critical VIs) I > haven't bothered making the spawned VIs reentrant since they > are copies and run just fine in parallel without (different > story for common Sub VIs that should run in parallel). If the > execution speed of the spawned VIs is very critical it is a > good idea to make them reentrant (or turn off debugging). > > > The last time I did this on a non-RT target (read PC) I also > embedded the spawned VIs as sub-panels on my top-level VI - a > great technique when controlling multiple identical systems > from one PC. > > > Tore > > >------------------------------------------------------------- > --------- > > > >Subject: Re: GOOP and spawning VIs on FieldPoint RT controller > >From: "Alex Le Dain" <[EMAIL PROTECTED]> > >Date: Wed, 26 May 2004 09:29:32 +0800 > > > >GOOP works fine. Re spawning the VI's, the important trick is to get > >the path correct; this takes a bit of figuring out and makes it a > >little harder to debug than usual. When debugging the "code" VI (I > >presume using the template technique) it can sometimes not > be updated > >down on the controller, so you need to download it any time > you make a > >change to the code to make sure you are running the correct version. > > > >cheers, Alex. > > > >------------------------------------------------------------- > --------- > > > >Subject: RE: GOOP and spawning VIs on FieldPoint RT controller > >From: "Jim Kring" <[EMAIL PROTECTED]> > >Date: Tue, 25 May 2004 22:13:55 -0400 > > > >Tore, > > > >I've employed the "spawning" pattern extensively on RT with > great success. > >There are a few tricks that will make things easier for you: > > > >1) I assume that you are using the spawning pattern of passing the > >spawned instance of a reentrant VI data via the "Set Control Value" > >method before invoking the Run method. Make sure that, in > your built > >app, the FP's of the spawned VIs are preserved by the App Builder > >otherwise the "Set Control Value" will fail. The easiest way to do > >this is to put a control reference or implicitly linked > property node > >on the BD of the spawned VI that links to a Control on the FP of the > >VI. This causes the App Builder to assume that you are using, and > >therefore need to preserve, the FP of that VI in the built app. > > > >2) One thing that I have done to avoid the path problems that Alex > >mentioned is to use a Static VI Reference (LV 7.0 feature) > to reference > >the spawned VI (instead of referencing by path). However, you can't > >invoke the Run method on a Static Refnum, so you will need to open > >another reference by reading the Static RefNum VI's name and then > >opening a reference, by name. This new reference have the > Run method > >invoked on it. But, remember to close this new reference -- you may > >want to pass it into the Spawned instance and let it close it itself > >(but be careful that you don't close it too early or the > spawned VI will halt execution and die). > > > >3) The Static VI Reference is also really nice because it > causes the VI > >to be loaded into memory and exist in the call chain of your > VI Hierarchy. > >This causes the VI to be included in the build and it also > causes it to > >be transferred to the RT execution target when you run your app in > >development mode. If you reference your spawned VI by path > and it is > >not loaded into memory, then it will not be uploaded to the RT > >execution target when running in development/debug mode. > > > >Cheers, > > > >-Jim Kring > ----------------------------------- > Tore Johnsen > Saint Bernard Engineering, Inc. > Phone: 651-494-9073 > Email: [EMAIL PROTECTED] > http://www.saintbernardengineering.com/ > > >
