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 > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Alex Le Dain > Sent: Tuesday, May 25, 2004 9:30 PM > To: Tore Johnsen > Cc: [EMAIL PROTECTED] > Subject: Re: GOOP and spawning VIs on FieldPoint RT controller > > 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. > > At 03:02 PM 25/05/2004 -0500, you wrote: > >Dear All, > >I wonder if anyone has tried using GOOP 1.0 and/or spawning VIs on a > >FieldPoint RT controller? > >I know it sounds a bit crazy but here goes: I have an > application where > >I'm independently controlling up to 12 identical test stands - each > >only needing a few digital outputs (there are a few > additional inputs > >to the system as a whole). Since the loop-time isn't very > critical for > >this application (100ms loop-time would be more than sufficient) I'm > >considering simplifying the core of the software by making > one control > >VI for one test stand and spawning as many copies as needed at > >run-time, meaning there will be up to 12 control loops (+ > 1-2 loops for > >application level I/O) running at the same time. I'm also > considering > >using GOOP 1.0 so there in effect will be up to 12 identical > objects. > >Again, this would be crazy if I didn't already have easily reusable > >code to handle the support functions needed. Have anybody > tried using > >similar techniques running an embedded application on a > FieldPoint RT > >controller? Any reason why this wouldn't work? > > > >(I'm receiving the info-labview digest so I'd be grateful to also > >receive responses directly to my email address) > > > >TIA, > > > >Tore > > > > > >----------------------------------- > >Tore Johnsen > >Saint Bernard Engineering, Inc. > >Phone: 651-494-9073 > >Email: [EMAIL PROTECTED] > >http://www.saintbernardengineering.com/ > > > > > > Alex Le Dain > Software Engineer > > Poseidon Scientific Instruments > 1/95 Queen Victoria Street > Fremantle WA 6160 > AUSTRALIA > > Ph: (+61 8) 9430 6639 > Fx: (+61 8) 9335 4650 > Web: www.psi.com.au >
