Re: Multiple Plots In Seperate Windows
Thanks thats really similar to what I am doing its just that my main form sends data which is causing the flashing. This design is a great idea. Thanks a MILLION for your help and time!
Re: Multiple Plots In Seperate Windows
ithats really similar to what I am doing its just that my main form sends data which is causing the flashing.=A0/i --- I would suggest putting the data into a separate global function (better than global variable for non-trivial amounts of data), and letting the slaves pull it out. At least that's what I did. i This design is a great idea.=A0/i I can't send the code, as it was contract labor. iThanks a MILLION for your help and time!/i Please send check for one MILLION to: ;-
Re: Multiple Plots In Seperate Windows
I actually got mine working with out using occurances. What benefits would I get by using them? As of right now as can be observed in my code, I just having everything in a while loop. I imagine this is as ineffiecent as possible due to constant polling. Is this what occurances would eliminate. Thanks.
Re: Multiple Plots In Seperate Windows
i The way I have wrote it causes the windows to lose and gain focus as expected.=A0 Does anyone know how to stop the focus from constantly changing?=A0/ip The focus is changing because the execution is changing (in the same thread). You have the VI with the graph execute, and then quit. This will lose focus. My occurrence-based scheme had all child windows executing at the same time (different threads). This meant that the window on top had focus - no other window would have it until you clicked on that window (and brought it forward). Hope that helps.
Re: Multiple Plots In Seperate Windows
You have a rather hairy state machine going on (I looked at your code again). The difference I see is that you have ONE button which spawns window #1 or window #2 or window #3, depending on who's up already. But the logic to support that is part of the polling process of every loop. My app had one button for each window (each window was different). My reason for using occurrences was to eliminate all execution paths between the main and child windows. In other words the main didn't CALL the child directly, so therefore, they became parallel independent processes. This led to the correct behavior as far as windows on top, who has focus, etc. There are probably other ways to do it - VI server, for one. I did this project in 6.0 and didn't know about VI Server then.
Re: Multiple Plots In Seperate Windows
I can see why you used occurances and agree that I think they will solve my remaining problems. How do you get the refrum of an occurance on another form and why do you put them in a shift register?
Re: Multiple Plots In Seperate Windows
Occurrence refnum controls are on the REFNUM palette - you can pass them thru connectors, or make globals out of them. Or you can pop up on the GENERATE OCCURRENCE terminal and choose CREATE INDICATOR or CREATE CONTROL. The Shift Reg. is just a place to store them. You could probably use global variables in this case and be OK. (A global function can store things in a shift reg and have advantages: it's inherently atomic - and if the data is large, a shift reg uses less memory than global variables (no unnecessary copies made). In this case those advantages are probably not relevant. I have a tendency to encapsulate everything.
Re: Multiple Plots In Seperate Windows
iwhy do you put them in a shift register?/ip Also, at the time, I didn't realize that Occurrences were special, in that a given instance of the GENERATE OCCURRENCE function will always refer to the same occurrence, even if it's been called before. In otherwords, the function that generated them didn't NEED to store them. For this reason, you can't make an array of refnums by using GENERATE OCCURRENCE inside a loop - the array of refnums will all refer to the same occurrence.
Re: Multiple Plots In Seperate Windows
You have mentioned Global Function multiple times, what are you refering too? I have not seen anything refered to as that.
Re: Multiple Plots In Seperate Windows
A global function is a VI whose principal job is to store some data (typically in the shift registers of a WHILE loop with LOOP set to false). At one time (LabView 2 and earlier) there were no global variables. The way you stored something for use by two or more independent VIs was to have a VI with a READ/WRITE switch input, a DATA input and a DATA output. If you called it with WRITE = TRUE, it stored the data you gave it. If you called it with WRITE = FALSE, you read out the data it had stored. Advantages: 1... You don't make copies of the data when you read it. That's important for memory usage when the data is a 200x64*512 array of CDB (I've used it like that). 2... It's atomic. If you want to store 6 separate items into six globals, you have the problem of knowing when ALL items have changed. Whatever reads them might read them during your change, and read 3 old values and 3 new ones. The global function is guaranteed to deliver the data as a set. 3... You can add functionality. I like to encapsulate things - for example: a config file handler. I like to have a handler (global function) for each type of config file. It has a FUNCTION input, which typically has functions like INIT, SET DEFAULT, READ FILE, WRITE FILE, COMPARE, and so on. The actual config is stored by this VI (in a shift reg, natch). Anybody who wants to deal with a config file calls this VI. That way, anytime I need to change something involving a config file, I have ONE and ONLY ONE place to go. In my multi-window project, I used a global function to create, store, and manage the occurrences.
Re: Multiple Plots In Seperate Windows
That is what I thought you were refering to. Which should bring me to my final question. I finally have a fully working model using almost the exact method you perscribed. My last question lies in transporting the data to the plots. Right now I have a re-entrant VI that has 6 simulated signal sources and puts them in an array. I placed a copy of this VI in each plot. Is this the most effiecent way todo this? Soon the simulated signal sources will be DAQ express VIs and I wasnt sure if I shoud localize and than transport it VI queue or global variable or something I am not aware of. It sounds like the way I am doing it now is a global function as you described but I want to make sure by having as many copies of the VIs as plots I want to display on the screen that this is memory and processor efficent. I really wish I could mail you a thank you card or something you have been a life saver. Thank you so much! I will keep learning so maybe one day I could help you.
Re: Multiple Plots In Seperate Windows
I don't have time to figure out xeactly what you're doing, but here's some ideas from a previous project I did - maybe they'll fit: The project had one main window, and six sub-windows. The main window had a button for each sub-window, to call it up. Each sub window ran on its own, offering a different view on live data being taken by the main. Each window operated as expected - it stays in front if you click it - you move them around like any other windows. You couldn't click the CLOSE box, but each window had its own DONE button which closed it. Here's how it worked: 1... A Window Manager vi was initialized (from the main) to generate six OCCURRENCEs and store them in a shift reg. 2... A Window Launcher vi is started. It first calls the WINDOW MANAGER to obtain the OCCURRENCE refnums, then launches six parallel WHILE loops. 3... Each WHILE loop has a WAIT ON OCCURRENCE function. It waits a specific time (500 mSec in my case). 4... If the WAIT ON OCCURRENCE timed out, we simply check the state of a global PROGRAM RUNNING variable, and loop if it's true. 5... If the WAIT ON OCCURRENCE did NOT time out, then it was triggered, and we call our particular sub-window (there's one WHILE loop for each window). The sub-windows are set to show front panel when opened, and close when done. 6... Each sub-window monitors the PROGRAM RUNNING global and stops if that is false. 7... Periodically, the six main buttons are fed to the window manager's CHECK function. This checks each button, and if TRUE, calls OPEN or MOVE to FRONT VI with the path to the associated sub-window, and the occurrence for the associated window. 8... The OPEN or MOVE to FRONT vi opens a reference to the associated VI, and checks the FP Open property to see if it's already open. If it's already open, the FP.IsFrontmost property is set TRUE to bring it to the front (one might click on the main button while this window is hidden - this will bring it forward). 9... If the window is NOT already open, the associated occurrence is fired. The Window Launcher vi will then start it up. The windows do whatever work they need within themselves - it's not like the main is doing the plotting and sending data to the windows. It's more like the main is putting data into a common pot and whichever sub-windows are open (running) go and get it. Hope that helps.
Re: Multiple Plots In Seperate Windows
If you have a re-entrant VI in each plot window, then they are NOT showing the same data. The re-entrant attribute means that each copy of the VI has its own data space. In your sine-wave example, the results might be the same, but it's really two (or 3, or 4...) copies of the same data - not multiple views of a single pile of data. If all your windows are identical in function (mine weren't, but in your example yours were), then you want to put as much code into a common VI as possible. I'm not sure what your end result is trying to accomplish, but if I were trying to allow each window to look at a different channel, then I would have the main store data for all channels) into the global function, and have each window call that function with a request for channel 2's data or channel 3's data or channel 2 vs. channel 3 in X-Y format. Make the global function do the work of extracting the requested data and assembling it into a plot. The plot window then just calls the global function with a request to get channel X, and puts the result into a graph. Long story short: Put as much code and data as you can into a common place, leave as little as possible in the multiple copies that are showing. i really wish I could mail you a thank you card or something you have been a life saver.=A0 Thank you so much!=A0 I will keep learning so maybe one day I could help you./ip Your payment will be to stay on the forum and answer somebody else's questions now and then.
Re: Multiple Plots In Seperate Windows
I fixed the focus problem by changed the window property to floating. The only problem I have left (I have made several changes since the version you looked at) is that when I change the comboboxes it stalls the graphs. Would occurences fix this?
Re: Multiple Plots In Seperate Windows
p iI fixed the focus problem by changed the window property to floating.=A0/ip That's not a good fix - although the focus quits flashing, the windows don't - you can't control the Z-order (who's in front). Overlap the windows and see. The occurrences simply controlled the launching of the windows, not the distribution of data. Once a window was opened, the occurrence played no part until that window was closed and opened again. The key factor was that the code in each window was running at the same time as all other windows. Your scheme still has the window display new data and stop. Therefore you're tied to the fact that the parent has execution most of the time.
Re: Multiple Plots In Seperate Windows
I look around a lot to see if I can answer questions but I havent found any yet that I have half of a clue how to answer. I have only been using LabVIEW since Feb. Thanks for everything.
