Real-time output from a sub-vi

[CGalvin]

Hello again.

I have been struggling with bringing an idea to life, and I'm not even sure it is a possibility in LabView. Maybe some of you here have some insight.

I have a vi that collects data over a period of time and spits the info onto a graph. When running the vi on it's own, I can watch this graph get drawn in real time as data is collected.

Now, I would like to use this vi as a module in a larger circuit, but when I use it as a sub vi the module runs all the calculations internally and only gives me the data once the entire operation is complete. I would like to continue to watch the data as it comes in rather than only being able to check the final 'report' given by the sub vi.

I have played with clocks, loops, and feedback circuits in an attempt to hack together a solution, but I am beginning to think that the basic vi structure I am dealing with is incapable of running with this behaviour. Is there something I am missing? Or is this honestly a difficult or even impossible task?

[shoneill]

Hello again.

I have been struggling with bringing an idea to life, and I'm not even sure it is a possibility in LabView. Maybe some of you here have some insight.

I have a vi that collects data over a period of time and spits the info onto a graph. When running the vi on it's own, I can watch this graph get drawn in real time as data is collected.

Now, I would like to use this vi as a module in a larger circuit, but when I use it as a sub vi the module runs all the calculations internally and only gives me the data once the entire operation is complete. I would like to continue to watch the data as it comes in rather than only being able to check the final 'report' given by the sub vi.

I have played with clocks, loops, and feedback circuits in an attempt to hack together a solution, but I am beginning to think that the basic vi structure I am dealing with is incapable of running with this behaviour. Is there something I am missing? Or is this honestly a difficult or even impossible task?

User Events, Queues, Notifiers. These will all enable you to do what you want.

Simply define the method you require and pass a valid reference to the sub-vi as an input. You can then put the data in the Event / Quque / Notifier int he sub-VI and it will be available to be read in your calling VI.

It's not that difficult. Search for some examples.

Shane.

[CGalvin]

User Events, Queues, Notifiers. These will all enable you to do what you want.

Simply define the method you require and pass a valid reference to the sub-vi as an input. You can then put the data in the Event / Quque / Notifier int he sub-VI and it will be available to be read in your calling VI.

It's not that difficult. Search for some examples.

Shane.

Alright. I got a working example going. Thanks Shane!

I will play around with the notifications to learn their quirks and limitations. I'm noticing that if the sub vi is particularly small, the notification solution is more complex than simply unpacking the vi's insides into the place the real-time data needs to be written to. I'll see if I can make a simplified wrapper for the notification modules to minimize this complexity in the basic cases I will be using it for, but I can see that for several sub vis I have here notifications just aren't an appropriate solution, partially due to the fact that I am a little over-zealous with packaging small circuits into their own vi's for reuse.

[Ton Plomp]

Be aware that if you use notifiers you can loose data if you don't read fast enough.

Ton

[CGalvin]

Be aware that if you use notifiers you can loose data if you don't read fast enough.

Ton

Will do. I assume the memory buffer a queue provides gets around this data loss.

As a side note, I was amused to learn of the term 'FILO queue' rather than the more widely used 'stack'. I'll get the hang of this software some day, I swear

[MikaelH]

You could of cuase just wire a reference for an additional Graph from you main VI down to the sub VI, so every time the graph in the Sub VI gets updated the "Copy" graph get the same updates.

//Mikael

[PaulL]

You can also used networked shared variables.

For instance, create a shared variable of the proper type in the project.

Drag the shared variable onto the block diagram where you want to write the value. Change to write mode and wire it up!

Drag the shared variable onto the front panel where you want to view the value. LabVIEW will create a bound control. Change it to an indicator. (If you want to use a chart, you can add a chart and then point it to the shared variable.)

You can customize the properties of the shared variable for buffering and so on. (There is a lot more you can do here, but just doing this will satisfy the need you have expressed.)

Networked shared variables offer an advantage over the other methods thus far proffered (which will all work, by the way) in that the View need not be on the same computer as the Controller. Shared variables also use the NI Publish-Subscribe Protocol, so that it is easy to have multiple subscribers (e.g., multiple Views) for a message. [You can register for shared variable value change events as well, but this functionality (strangely and unfortunately!) is only available with the DSC module.]

[CGalvin]

Nice! References and shared variables are so simple I'm disappointed I didn't think of it myself. Thanks for the tips. I've got a lot of reading and experimenting to do now!

[jdunham]

Nice! References and shared variables are so simple I'm disappointed I didn't think of it myself. Thanks for the tips. I've got a lot of reading and experimenting to do now!

I feel like people haven't mentioned the obvious here: You can also set your VI to show when called, or else drop it in a "subpanel control" if you don't like the popup window. This way you can get the same data view you are accustomed to with the least amount of programming.

[PaulL]

One thing to keep in mind is a common design paradigm called Model/View/Controller. The idea is to keep each of these distinct. In particular, if the View is distinct from the Controller, it is simple to create alternative Views of the data from the same Controller. This is one reason why the Observer Pattern (a publish-subscribe paradigm) is, well, a Design Pattern.

LabVIEW makes it easy to put an indicator on the front panel of a VI and some control code on the block diagram of that same VI. This is OK for debugging, but it doesn't allow for easily scalable solutions, so, yeah...don't! MVC is much more powerful in this regard!

[This is consistent with two other design principles: loose coupling and tight cohesion. Essentially group things that really belong together in one place (tight cohesion) but separate things that should be independent (loose coupling). Decoupling the View from the Model leads to a system that is much more scalable and maintainable, because one can change the View, the Model, or the Controller without (necessarily) having to change either the other two. I recommend considering this when selecting a design solution, as some solutions offer this and others do not.]

[A brief discussion of MVC does appear in the introduction of the classic Gang of Four Design Patterns book in a discussion of using the Observer pattern and other patterns, but the details of implementation are really outside the scope of that text.]