No response from the "STOP" button

[terp]

Hi, I was writing a labview program, which does a live image display, see the attached excerpt.
As you can see, there are three buttons in the front panel: "Quit" button will stop the program; "Live Image" will trigger the live image display and "Stop" is supposed to stop acquiring the live image.
But when I run the program, after I trigger the live image display by pressing the "Live Image" button, there is no response from the "Stop" button if I try to press it. I don't know why this happens. Can someone help me out here?

[jpeters]

You have the Lock Panel option checked on this event case. This means that LabVIEW will not respond to any more mouse clicks until the event structure finishes. Of course, the event structure won't finish until you hit the button. This puts your VI in an bad state. You should uncheck this option from the event structure on the cmdChangeDisplay value change event at least.

That being said, you probably shouldn't sit in the event structure while you acquire images. Instead, you should build an application that doesn't wait for your image acquisition to finish.

You can accomplish this by calling a subVI with an invoke node and setting the "Wait for finish" param to FALSE. To stop it, you have a bunch of options depending on the architecture that fits
your needs.


Off the top of my head you could do this by:

1. Watch for the value change event in the subvi itself. This can be done by acquiring a reference to the button on the top level application and registering for the event dynamically.

2. Acquire a referece to a boolean inside the subvi and set the value. The subvi can poll it.

3. Set a global variable that the subvi polls.

4. Forcefully quit it with invoke nodes.

If you want an example of any of these solutions please feel free to respond and I can provide them.

Jeff Peters
LabVIEW R&D

[Ben]

Actually this sounds like an case for a "queued message handler". Search this site, there are examples under that name and also linked under the "design Patterns" topic. AN example can also be found by doing a search in the LV help find examples by searching on queue.

The "Queued Message Handler" design pattern seperates out the response to user events from the work associated with those stask that can not be completed quickly (ie fast enough to look like it is still alive.).

The event structure would submit a request to a queue and then be ready for the next mouse click.

Meanwhile... In another loop...

The request is found in the queue and process just the same way as before, but this time the event structure is not locked-up.

If you need t
o know when it completes, look at the design pattern the Jim Kring posted on the LV ZONE. It provides a mechanism to signal the requesting entity that the work has been completed.

So....

Try out a "Queued message Handler".

Ben

[jpeters]

Yes I agree. I didn't know there were examples of such an application, but this does sound perfect for this application. It may be a little more work than my suggestion, but in the long run will probably make your application more extensible. Good thinking.

[terp]

Thanks Jeff!!

If you don't mind, can you provide an example for solution 1&2. You can either post it here or email it to me, cyang@genospectra.com

Thanks again for your help.

[jpeters]

I wrote the examples that you asked for, but they both seem kind of kludgy to me. I didn't really solve your problem as you probably want the display updated as you aquire which is pretty difficult in a subVI unless you use a subpanel.

I also wrote an example using queued messages and it seems much less hacky and better than my examples. I think that this is probably what you really want.

In the llb are

IDT3_test (#1)
IDT3_test2 (#2)
IDT3_test3 (Queued messages)

[Ben]

IDT3_test3 is what I had in mind!

This example should solve the problem cited in the original Q.

Notes:
I do not believe the shift registers are required. Their values never change.

Quit app should destroy the queue.

Nice example, no frills, demos idea.

Ben

[terp]

Thanks! You two are the best.

I want to look back at the original (my first) solution. What is the fundamental problem you see if I unlock the option for the event structure, which is the image acquisition sits in the event structure?

[jpeters]

There are a lot of problems with this way of handling it. You will get a lot better results if the event structure is allowed to operate without delay.

One reason for locking the panel in the first place is to aviod UI race conditions. Take, for example, the button that quits the application. It is hidden when the acquisition starts. On a busy machine LV may be unable to notify the diagram of the value change on the start acq button and there is a small sliver of time when the button to quit the app can still be clicked. In your case this doesn't matter because you use the same event struture to handle it, but in many other application this may be a problem. Locking the panel guarantees that the processing of the value c
hange event is complete before you start handling other events. I didn't account for this in my example, you probably want to hide or disable the quit button in the event struture then queue up the acq. This way the user cannot quit the application while you are acquiring images.

Even if the reasons for locking the panel don't apply to you your application can still get into problems that you were experiencing before. If for some reason you need a filter event (or any other panel locking event) for your VI down the road, it will lock the panel automatically until you can handle it with the event structure. Of course, because the acq is inside the event structure until you hit a button, you will be in a state where you cannot quit your application.

There are probably a lot of other reasons that I am forgetting and these are only examples off the top of my head. I think that the other (queue messaging) example is a good model to follow.

[terp]

UI race is definitely one of the problems, if not all. I've already experienced that in my program with my slow PC.

Let me ask one more question, if you don't mind. I tried to implement an analysis section in my code (see the attached code). If the "Analysis" is pressed, it's supposed to get a snap shot and acquire the centroid for the particles. I used "Cast Image" function because the image acquired from my camera is 16bit.

But when I ran the code, it gave me some weird error. My guess is something to do with the management of the image memory. What do you think?