Thanks (was: RE: Not quite off-topic: List misuse)
John, thanks for your response. I did not intend to start a long discussion questioning the list policy. IMHO the official policy of allowing short product/company notices has worked well in the past to everybody's benefit. Considering how carefully I've controlled access to this email address and the timing of the ad I did find sufficient reason to react. John, with your response I have no longer any reason for complaint and I wish you and your company well. I'll remove myself from this thread and take any further discussion of this topic in private. -Tore At 09:53 6/1/2004, John Toto wrote: Sorry Tore. Your name was in our database and a special Data Acq. email ad was sent. I believe that is the only one you have ever gotten since we went deep into our data base. I'm very sorry for that. Your name was removed. No, I do not mine this or any other site for emails. I have no need to. I'm sure other members of this list may have gotten an email, but I doubt more than a few. You either have to email, phone, purchase or otherwise request to be on my list - but the database is large and I can't speak for each record. Again, sorry for the inconvenience. If anyone received one and wants to be removed just send me an email with remove in the subject and I will personally do it. Best Regards, John John C. Toto Sales Director SUPERLOGICS, INC.
Not quite off-topic: List misuse
Dear list, I recently received a full-blown advertisement (SPAM) from a company that uses THIS LIST to gather email addresses. The sender is a member of the list: John Toto at Superlogics. I don't at all mind members peddling their products in direct response to questions posted to the list (as John has done before). That can actually be quite helpful. However, when it degenerates into full-blown full-page unsolicited advertisements with all the bells and whistles sent directly to members of the list - well that's when I make a NEVER BUY FROM entry in the list I keep for that purpose. Sorry John: Gotta try to nip this in the bud before it degenerates further. - Tore
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
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/
