AW: More then one active Vi with open Front panel? Preliminary summary
Hi all, I am really impressed about the number and quality of answers / comments / recommendations my question has initiated. I still have to think about the different aspects of the suggestions, but I am learning a lot out of each one. As I will be out of the office for the next week, I will not be able to commence on this job too soon, nor to follow the rest of the remaining discussion about parallel while loops in "live mode". Preliminary summary: There seem to be different solutions: 1. use parallel loops 2. use VI server (Run VI, Wait until done, Auto Dispose Ref), maybe together with ocurrence to control the loops 3. "Selective GUI Panel Control" by David Ritter. I still have to learn more about this. Many thanks to everybody and keep on going. Gerd Rech -Ursprungliche Nachricht- Von: Michael Aivaliotis [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 7. Mai 2004 05:13 An: [EMAIL PROTECTED] Cc: 'Info LabVIEW (E-mail)'; [EMAIL PROTECTED] Betreff: RE: More then one active Vi with open Front panel? Well I'm not arguing the idea of eliminating multiple loops. I definitly use the concept in every app I write. I'm stating that parallel processes shouldn't necessarily be tied to the main user interface VI by being contained on the diagram of that VI. Yes, it is comforting to "see" your code in the main menu but it is easier for me to debug parallel code when it is not linked to a caller. Sometimes I need to abort a a parallel process and restart it. The caller remains unnafected. I usually launch several dynamic VI's for hardware communication and it is more convenient to keep my main app running while I tweak things here and there. Also, certain concepts like cloning VI's cannot be achieved without dynamic calls (Gerd, you might want to consider this in your case, multiple views of the data). Let's not forget that this thread is trying to solve a problem of launching a VI so it is non-blocking. I really don't see the big deal with dynamic calls. I guess the phrase "VI Server" conjurs-up images of complex code to perform a simple task. I think the parallel loop ideas with occurences and such sound more involved to me (even though I've used them myself). Honestly, is this code scary?: <http://lavausergroup.org/labviewimages/dynamicrun.gif> :-) That's really all you need. Michael Aivaliotis > "Michael Aivaliotis" <[EMAIL PROTECTED]> wrote: > > > My problem is I enjoy discussions on methodology and implementation > > techniques too much. In our local LabVIEW user group meetings we > > sometimes (actualy always) discuss (actually argue) > programming style. > > The issue lately is: single loop good, multiple loops bad. > > Are you kidding? Most complex programs I write never would > fullfill user expectations without multiple loops in the main > VI. You don't want to block alarm handling or built in TCP/IP > server handling for remote control because a user wants to > check the configuration settings. Of course making sure the > local user and the remote application are properly locking > out each other is another thing, but quite some remote > commands do not need local lockout to be performed at all.
AW: More then one active Vi with open Front panel?
Couldn't I put the subvi's in a true case and nothing in the false case within the separate while loops? Control the case using a local (h, that bad word again) from the state machine. Maybe it is not best programming style, but would be quick to implement in this existing project Gerd -Ursprungliche Nachricht- Von: Michael Aivaliotis [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 5. Mai 2004 16:48 An: 'Paul F. Sullivan'; 'Gerd Rech' Cc: [EMAIL PROTECTED] Betreff: RE: More then one active Vi with open Front panel? How do you suggest that the subvi's get called? What method would you use to command the subvi's from the state machine? Just curious... Michael Aivaliotis > Gerd, > > You asked, > > >...The main VI is basically a state machine waiting for user > clicks to > >go to one of the sub VIs, which e.g. displays a xy chart of > >measurements... How can I get the main VI to commence working (not > >waiting for the chart window to complete and return)? > > Michael responded, > > >You will have to use VI Server to do this... > > While Michael's approach will work and is probably preferable, I > think you might also accomplish the same thing by putting each of > your selectable subVIs in its own loop parallel to the state machine > loop. Use the state machine to enable the execution of the > appropriate subVI for one iteration of the subVI's loop. One loop > being held up until its subVI closes will not interfere with any > other loop, including the master state machine's. > > -- > EnWirementally, > Paul F. Sullivan
More then one active Vi with open Front panel?
Hi all, seems like a beginners question, but I can't figure it out myself: I have a project with several VIs and sub VIs in maybe 4 hierarcy levels. The main VI is basically a state machine waiting for user clicks to go to one of the sub VIs, which e.g. displays a xy chart of measurements. Up to now the user always had to close the chart window (go back to main) before he could select a different sub VI (e.g. for changing some settings). Now a customer wants to get direct acess to other sub VIs (frontpanels) without closing the chart window first. But the main VI does not respond to user input as long as the chart window is open. The buttons just go to ON when clicked, but the state machine does not react until thechart window is closed. How can I get the main VI to commence working (not waiting for the chart window to complete and return)? There are examples in the LV directory which seem to behave simmilar to the way I would like it (the semaphore example), but I can not see what is the important difference to my project? I have looked at the run options of the sub VIs. They are set to "run when opened" and the frontpanel to "open when called". I know that there are new methods for controlling the user interface, but I do not want to rewrite the the whole thing. The project is in LV6.0. Could probably migrate it to 7, but would like to avoid that. Any ideas? Cheers Gerd
Re: [W6.1] RMS averaging with "FFT Spectrum (Mag-Phase).vi"
Hello all, many thanks for all your comments concerning the mechanisms of FFT averaging. I do see several things clearer now and surely can find my way from here. Unfortuately I have to complete an other job first, before I can continue working on the FFT. Best Regards Gerd
AW: [W6.1] RMS averaging with "FFT Spectrum (Mag-Phase).vi"
I have a phase reference pulse once per rev which starts the acquisition. So I should get consistent phase readings for repeated measurements. However, I was wondering if it would make sense to average parts of the signal(using overlapping segments) for speeding up the averaging process. The idea is to make as much use as possible out of the data that I get into the PC. Gerd -Ursprungliche Nachricht- Von: Bruce Ammons [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 4. Februar 2004 15:27 An: 'Gerd Rech'; [EMAIL PROTECTED] Betreff: RE: [W6.1] RMS averaging with "FFT Spectrum (Mag-Phase).vi" The only way to get meaningful phase is to start your acquisition at the same phase for every segment. An example of this would be an encoder pulse. If each acquisition starts at a once per rev pulse from the encoder, they will all have the same phase components. Another possibility is doing order tracking, where there is a fixed number of samples per revolution. If you shift your window by the number of samples per revolution, you will get the same phase again. Any time you have a steady stream of data with no reference point, the phase data is essentially useless. If it is a repeating signal you should be able to identify a reference point. I suppose if you don't have a hardware signal, you could use convolution to identify repeating cycles of data. If phase is important, you should have a reference signal. Bruce -- Bruce Ammons Ammons Engineering www.ammonsengineering.com (810) 687-4288 Phone (810) 687-6202 Fax -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gerd Rech Sent: Wednesday, February 04, 2004 3:36 AM To: [EMAIL PROTECTED] Subject: Re: [W6.1] RMS averaging with "FFT Spectrum (Mag-Phase).vi" Hi folks, I know the "overlapping average" technology from signal analysers. In those cases I used them up to now, phase was not relevant. Now I have an idea about a different use where phase would be important. Scott's comment that phase would be meaningless if overlapping averaging is used is making me thinking. What about this: 1. Cut the long waveform stream into a number of (overlapping) pieces. 2. Use the FFT vi for each piece, which will produce amplitudes and phases for each frequency bin. 3. Average apmlitude and phase for each frequency bin separately. Would this create meaningful phase? I would guess yes, as all pieces were acquired in a consistant stream of data originally. Seems that my mathematical understanding does not reach far enough to understand this completely. Cheers Gerd
Re: [W6.1] RMS averaging with "FFT Spectrum (Mag-Phase).vi"
Hi folks, I know the "overlapping average" technology from signal analysers. In those cases I used them up to now, phase was not relevant. Now I have an idea about a different use where phase would be important. Scott's comment that phase would be meaningless if overlapping averaging is used is making me thinking. What about this: 1. Cut the long waveform stream into a number of (overlapping) pieces. 2. Use the FFT vi for each piece, which will produce amplitudes and phases for each frequency bin. 3. Average apmlitude and phase for each frequency bin separately. Would this create meaningful phase? I would guess yes, as all pieces were acquired in a consistant stream of data originally. Seems that my mathematical understanding does not reach far enough to understand this completely. Cheers Gerd
