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/
