having more than one popup graph, possible?

[Ben]

Please review Dennis' earlier comments and refer to the attached diagram.

I hope this helps,

Ben

Message Edited by Ben on 10-20-2006 07:24 AM

[AZVerdugo]

Hello!

   I've done what you told me about calling dinamically a template. Every time the template is called a new VI is created, and if there is no one popup running, it will work. But if there is one opened, the second one does not reach the running state, as you could see in the execution of the files. The behave persists, as you can check. I think I'm doing things right, and maybe the reason because I can't have more than one VI running (apart from the main VI) seems to be a limitation of the 7.1 version, or maybe I'm wrong.

  Does any of you got the desired performance?

  Having more than one VI running at the same time is very important in my application, because there is more VIs (that make other different things than representing acquired data). Those VIs are not running in normal state, but it has to be possible to launch more than one at the same time, as the operator needs. For instance It's very interesting to register data at a higher speed and to monitor 2 or 3 pop-up graphs to understand what is happening.



Thank you again

Alfonso

[AZVerdugo]

I forgot the files, We are not going so far without them 😉


Alfonso

[Dennis_Knutson]

Your program does sort of work though it needs some more modifications. I ran it and could get it to pop-up both at the same time. You might have to move the first pop-up before the start the second. Otherwise, you could have one on top of the other. It was pretty flaky though and I think you have some race conditions going on with the misuse of global variables and there is an error in the timed loop in the subVI. It looks like you've got them named the same and that creates an error.

Message Edited by Dennis Knutson on 10-20-2006 09:20 AM

[AZVerdugo]

Hi Dennis!

   Thank you! I've just fixed the problem. As you told, the problem was that the instantiated loops had the same name. I've made some changes on the template and it works. I also would like to thank everyone who has interested in this thread.

sincerely


Alfonso.

[DFGray]

Queues are your friend.  They make this sort of thing easy.

1. Use queues to pass data to your pop-ups.  You can pass the queue reference to the pop-up when you start it.  This allows you to write the data directly to your graph without the ineffeciency of a property node.  If you create your pop-ups with a queue-driven state machine architecture, things get even easier.
2. You can use queues to get data back from the pop-ups as well.  This allows you to do such things as deteremine when the pop-up has finished initializing.  Once again, create the queue before you start the pop-up and pass the reference to it.

Use of queues means you don't have to worry about creating a bunch of uniquely named global variables.  It also almost eliminates the need to pass control references around.  There are other methods (e.g. notifiers, events) that can be used in a similar fashion.  I urge you to take a look at them.

This sort of architecture has been possible in LabVIEW for some time.  There are several NI applications which use it.  The NI-SCOPE Soft Front Panel, designed in LabVIEW 6.0, has multiple front panels (one for each device) and multiple child windows, all active at the same time.  It was done with VITs.  Internally, it uses a waveform buffer for each data trace which is implemented as a reentrant LV2 global VI called by VI server - one copy per trace.  SignalExpress uses VITs for the multiple copies of function blocks.

You have already found a few of the hidden gotchas, but just to be on the safe side, here is my checklist for successful pop-up use.

1. Any function which may cause blocking and is used in common by the pop-ups must be reentrant.
2. Do not used named queues, semaphores, notifiers, etc, unless the names are dynamically generated and keyed to the particular pop-up.  You can used unnamed versions of these with no problem, as long as you generate a new one when you need it and remember to close the old ones when done.
3. Do not use global variables to pass data, since they cannot be programmatically created and destroyed.  Use by multiple pop-ups creates complicated code to avoid collisions.  Much better to use something else (e.g. notifiers) which can be dynamically created as needed.

Good luck.  Let us know if you have further problems

[AZVerdugo]

Hello DFGray,

   I'm sorry. This is the first time I'm reading your reply. All you have told me it's new for me, so I'll have to study how queues and other resources work. Give me some days to do that, and I'll tell you if I success. Also, I'm going to show you in a video file the final performance.

  One of you told me it is not necessary to show "N" pop-ups at the same time to the operator, and that's true. One thing I'm going to do is create a maximun limit to the showed graphs. So, I don't know if it is worthwhile to change all the architecture. Despite that thing, I'm going to try because I want the best performance for my application.

My best regards,

Alfonso.

[AZVerdugo]

Hi DFGray, Here are my answers of your comments:

Queues are your friend.  They make this sort of thing easy.

I'm sure about it, my friend.

1. Use queues to pass data to your pop-ups.  You can pass the queue reference to the pop-up when you start it.  This allows you to write the data directly to your graph without the ineffeciency of a property node.  If you create your pop-ups with a queue-driven state machine architecture, things get even easier.

Popups are only used to display a 60samples array of aquired data. The property node is only use at the begining when the pop-up is launched. After that moment, no property node is used.

          You can use queues to get data back from the pop-ups as well.  This allows you to do such things as deteremine when the pop-up   has finished initializing.  Once again, create the queue before you start the pop-up and pass the reference to it.

It is not planned to be data exchange between a popup and the main application, except the reading of the array that is going to be displayed. I pass the reference to the popup to simplify the tasks of the main application. If the reference is passed, then the main application doesn't to worry about "wait until the popup finished" and it can continue doing other things.

Use of queues means you don't have to worry about creating a bunch of uniquely named global variables.  It also almost eliminates the need to pass control references around.  There are other methods (e.g. notifiers, events) that can be used in a similar fashion.  I urge you to take a look at them.

I understand what you meant, but if I want to use queues I'll have to use other resources to notify that there is a new element in the queue, to syncronize the writting and reading of the temporal and data arrays. (who are passed to the graph). Is it worth to use queues+notifiers instead of globals?

You recommended me not to use global variables because they can't be created or destroyed programmatically. The thing is, in my application, they have to be used continously, not only at one time.

Now, here is my question. Global variables are used in my application to keep the last 5min values of each signal. When the operator wants, He can launch a popup, and display the acquired signal. Do you think change using queues and notifiers (events, semaphores) instead of globals is worth?

Thanks in advance for your interesting and help.

Alfonso

[DFGray]

I made the assumption that a pop-up is updated by your data stream and that you have multiple data streams, requiring multiple pop-ups.  If the pop-up is static, you are better off just passing the data to it when it launches.  Wire to the graph as normal.  As mentioned before VITs work great for this sort of thing.  You can use reentrant VIs as well, if your version of LV is new enough (older versions did not allow reentrant VIs to display a front panel).

Queues will block when they do not have data (assuming the timeout is non-zero, I usually use -1, infinite), eliminating the need for a notification that new data is present.  In this type of application, I would set up a queue with an array data type and read it in a loop, wiring the result to the graph.  Each time I post something to the queue in the main program, the queue is then automatically read in the pop-up and the graph is updated.  To exit the pop-up and unblock the queue, simply destroy the queue with a "force destroy" set to True.  It will error out and unblock in the pop-up, which is the pop-up signal to exit.  If you want to exit the pop-up from a button on its front panel, you can abort it or force destroy the queue there.  You will need to signal your main program that the pop-up no longer exists.

I would use a LV2 style global (shift register or functional global) to cache the data, not a global.  This is because I can access the data faster and with less copies than I can through a global.  The fact that the data is contained in a VI also helps prevent race conditions, since operations should be atomic.  Globals do not have this capability.  If you don't have a lot of data, the change may not be worth it, since copies are not expensive.  Race conditions should not be too much of an issue.  I would use queues to pass the data to the pop-up, probably directly from the LV2 global.  However, I am not sure that changing at this stage is worth it for you.  I am somewhat loathe to change working code unless there is a reason.  If it is working and you are having no memory problems or race conditions, stay with what you have.