Spawn graphics on a separate window, on demand

[Daikataro]

Greetings everyone, what I want to do, is (due to user request), show three (possibly more) waveform charts on a separate window, but only when user requests them, so they don't obstruct visibility of the main VI and honestly, I'm lost at even where to start. They would have to be summoned by a boolean button or something like that, show up in a different window (dialog style VI or the such) and stay there until user closes the window, while not interrupting execution of main code. Now the tricky part is, they would have to be constantly updating, so the chart shows the histogram of the past few seconds like it does right now as an always visible (albeit, tabbed) indicator, what would be the best way to do this? Could anyone please point me to examples that do something like that, or what function or SubVi style should I use? Thanks in advance.

[Ben]

Somewhere about post #17 or 18 in this thread I posted an example of how to undock a poart of a GUI.

It may be helpful.

Ben

[ijustlovemath]

You'll want to go to VI properties and set the graphing VI to "floating", as well as "show front panel when called" and "close afterwards if originally closed". The way you would spawn it is via an event structure that in the main VI, in my opinion, should just open a VI reference, use the "Run VI" invoke node (with "wait until done set to false", or "Start Asynchronous Call" if you need to wire things into it. Within the graphing VI itself you could just have a single event structure, no while loop, and a single boolean button that says "done" or "close" or "continue" that would cleanly shut down the VI. Because it's floating, they can go back to the main panel without it pestering them, and because it's started asynchronously, it won't block the execution fo the rest of your code.

[Gregory]

It sounded interesting so I decided to code up a possible solution. You can implement it in many ways though 🙂

[Daikataro]

---

ijustlovemath escribió:

You'll want to go to VI properties and set the graphing VI to "floating", as well as "show front panel when called" and "close afterwards if originally closed". The way you would spawn it is via an event structure that in the main VI, in my opinion, should just open a VI reference, use the "Run VI" invoke node (with "wait until done set to false", or "Start Asynchronous Call" if you need to wire things into it. Within the graphing VI itself you could just have a single event structure, no while loop, and a single boolean button that says "done" or "close" or "continue" that would cleanly shut down the VI. Because it's floating, they can go back to the main panel without it pestering them, and because it's started asynchronously, it won't block the execution fo the rest of your code.

---

I think that would be the solution that would interest me the most Math, it sounds simple and doesn't add too much to the code which is already pretty wiry. I'm tinkering with the code, but just a few questions:

-The graph VI is constantly being called, because I am constantly sending new information to it. What could I do to just summon the front panel when user wants to see the data, instead of every time it gets new intel (10 times a second)

-Would the waveform charts hold previous iterations like they do as main panel indicators?

I think that, with those issues ironed out, such a solution would be quite feasible and simple to implement, thanks a bunch!

[ijustlovemath]

Waveform charts automatically hold all data until they hit their history size limit, or the VI is deallocated (usually when you shut down LabVIEW or the project you're working on). With that being said, I'd actually encourage you to look at gregoryj's solution, which has a much more classical LabVIEW queued message architecture that not only works better, but also will allow you to continually add data while it's in the background. If you have any questions on how it works (eg, Why is one wire outside the loop going inside both the graphing VI and the main loop? How do they communicate?) I'd be happy to field them.

[Daikataro]

I indeed looked into it, and I (think I) understand the functionality, problem is I already have a producer/consumer architecture in place, and it has several wires going in and out of it, so I would be less inclined to use it mostly due to readability than anything else, since this code will need to be as easy to read and understand as it can be, because I might not be the person in charge of debugging and expanding once it's finished. I will try creating a separate code that feeds off the waveform charts, which I will not show indicators for, and will tell you  guys how that goes.

[ijustlovemath]

You could also try using an action engine/functional global which may be more readable to a lay person, but you would face concurrency issues (only one thing can access the FG at a time), so IMO this architecture is the best way to handle things.

[Gregory]

Hi Daikataro, as ijustlovemath mentioned, you can clean up your top level diagram by hiding the queue reference inside a Functional Global. (A VI that uses uninitialized shift registers or feedback nodes to keep data from previous calls). And in practice, this is exactly what I do, but it makes it less clear what is actually going on under the hood. So, please make sure you understand my first example, and you can take a look at this one which cleans it up. Notice especially the obtain queue wrapper. On the first call (when the data in the shift register is not a valid reference) it will obtain a new queue, but on every call after that it will use the queue that it got on the first call.

[drjdpowell · Accepted solution]

If your popups just need to display information, then the easiest method is to just put your chart is a subVI which you call normally and then just show it's front panel.  As shown in the attached.