Re: GOOP and spawning VIs on FieldPoint RT controller
Tore Johnsen [EMAIL PROTECTED] 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). You can have templates with template SubVIs. For that you put the template subVI on the diagram by using the File Dialog from the function palette. A blue T should appear in the icon. Now on loading the template main VI LabVIEW also instantiates the template subVIs. I used that technique a few times for communication with the template main VIs by making the template subVI an intelligent LV2 style global. The main VI just starts up as independant task and sits there and runs and I retrieve the refnum to the created LV2 style template subVI to send commands and receive data through it from other places. Another way of communicating would be queues but my LV2 style global approach had some nice advantages for the application in question. PS: nice domain name by the way ;-) Rolf Kalbermatter CIT Engineering Nederland BVtel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijkhttp://www.citengineering.com Netherlands mailto:[EMAIL PROTECTED]
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/
RE: GOOP and spawning VIs on FieldPoint RT controller
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
RE: GOOP and spawning VIs on FieldPoint RT controller
Jim, I got it this time around. Neat. Thanks. Tore At 13:27 5/27/2004, you wrote: 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
GOOP and spawning VIs on FieldPoint RT controller
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/
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
RE: GOOP and spawning VIs on FieldPoint RT controller
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
