How to pass data between VIs

[Scott-D]

I am trying to build a generic plot function in LabView for my signal monitor application.  The plot screen should display the signals in waveform charts and what signal to display is totally configurable on the fly.  So given that, I think to create three VIs/front panels:

1. mainPlot -  call plotSelection panel to get selected signals and display them in waveform charts. The number of waveforms will be dynamically decided depending on the # of signal selected. Can that be done?

2. plotSelection – a listbox that to show available plot names/groups that are predefined signals in it. Once a plot name selected, it passes to the mainPlot panel to plot.  On the same panel, there is a button called “New Plot” that will bring another panel addNewPlot.

3. addNewPlot -  there will be couple of Listboxes to display on the panel. User can pick and chose signals to display for that new plot and save the new plot name that passes to plotSelection panel so that it can be visible in the Listbox on plotSelection panel and selected by user and finally is sent to the mian Panel to plot

My question is that, how can I pass the data between these VI panels?  The data includes plot name, signal names, etc…  I know how to create SubVI and passing data with connector and use Invoke Node to call another VI panel.  What is the best and easy way to communicate data between panels?  Or maybe there is a better solution to my problem.   Thanks a lot for your advice!

[MikeS81]

Hi Scott-D,
i recommend the use of queues or notifier. There are a lot of shipped examples. Did you already start programming? To answer your questions, everything is possible.

Hope it helps.
Mike

Message Edited by MikeS81 on 06-02-2008 08:45 PM

[Scott-D]

Mike,

I haven't done any programming yet.  Just prototype front panels.  I'll look for some examples with use of queues or notifier.  Thanks!

Scott

[Ben]

Excellent Q and I am sure my reply will not be satisfatory.

I've done that in an application where we decided to name that architecture "Advertise with SASE" (SASE=Self-addressed Stamped envelope) which I will out line below.

1) Clients

Clients consume the data being produced by a producer

2) Producer

 Producers send update to to any and all subscribers. They also advertise what channels they offer.

***********************************

The app uses an Action Engine to store the Names of data that is available (advertising) and a queue that goes with each Name.

Producers come up create a Marketting In-box" queue and posts the queue ref along with the Names to the AE. Then the producers start monitoring data and watchin gtheir "marketing in-box" queue. When Marketing detect an entry in its In-box (queue) it examines the message to see who want s to subscribe (but I am getting ahead of myself).

********************************

The Clients are instaciated from templates that check the AE for the availabel Names and populates a drop-down. User seelect a Name form the drop-down and the name is used to check the AE for the queue that represent the proper "in-box" for the marketing department to which it should send a request. It then creates a new queue from which it will recieve updates. THe newUpdate Queue (for this client) queues up a request to the In-box of the proper marketing department and include a ref to its newly created update queue. From that point forward the client just watches its update queue and updates the screen.

******************************************************************

So when the marketing department find a request in its subscribe request queue (SASE) it pass that queue ref to the code doing the DAQ. THE DAQ adds that new queue ref to its list of queues it should update.

************************************

So at the begining neither the client or the producer know anything about each other, but before it is done there are queue strung between all of the producers and thet consumers.

Ben

[Scott-D]

Ben,  thanks much for sharing the ideas and writing them up!  I'll do some experiment.

[Ben]

No problem Scott!

If you come up a demo for that idea please post it up so we can link to your example the next time this question comes up.

Ben

[Ben]

BTW: THe above outline was inspired by a Design Pattern developed by Jim Kring called "Jim Kring's Queued Message Handler with Response Notification " and can be found here.

Ben

[lmtis]

Ben,

Thanks for the link, that is an interesting construct.  I can see how that could be a useful design, but it sure seems (to this padawan) to throw data flow out the window.

[Ben]

Thank you for your comment Jim. The "Advertise with SASE" architecture was developed for an application that did not know at development time what data was to be collected and monitored. Configurable Plug-ins were used for acquiring data from "where-ever" but a standard method was required for monitoring any of teh potential 30,000 I/O points.

One all of the circuits are run (queues linked up) it was no-less data-flow dependent than your standard Producer/Consumer architecture.

Ben