Jump to content

Multiple While+Event-Nested Structures Not Behaving As Expected


Recommended Posts

Hi,

I'm building some LabView (8.6) code to do a simultaneous camera image capture and motor control. I put each of these in their own While-loops with an Event-Structure right inside looking for button presses to kick off each sub-vi. The camera capture is very CPU-intensive, and the motor control isn't (just steps when the button is pressed). But I am finding that when I start the camera capture, LabView is no longer responsive to anything else on the GUI (including a button which stops the capture!). I'm attaching a very much simplified test case for this "feature" of LabView that reproduces the behavior:

- Two while loops at the top level of the VI

- Two buttons at the top level also

- Each while loop has an Event Structure looking for one of the buttons to be pressed

- One of the buttons starts a process that finishes "immediately" in the lower While/Event structure

- The other button starts a time-consuming process in the upper While/Event structure

Steps to reproduce behavior:

1) Run the VI (I didn't reset buttons, etc., and, yes, there are two stop buttons, but don't worry about those things)

2) Press the Date/Time button on the left to your heart's content. It updates the display fine.

3) Start the counter with the button on the right (it'll activate on a transition to true)

4) Try to do anything with any other button on the screen (time/date, the two stop buttons), and you'll find that nothing works except the big kill button in the menu at the top.

This is not the behavior I expected. I thought that since LabView was multi-threaded, load-balanced, etc., that I would be able to do other things while the CPU-intensive process is working, even if those other things slowed down a bit. But they don't slow, they are simply not available. In fact, in my real code, I put that "long" process inside a Timed Sequence just so that I could assign it to the 2nd core of my dual-core system. I verified that it shifted the long process to the 2nd core, but I *still* could not use anything else on my VI's GUI.

Could this possibly be correct? I can't imagine that being the case. Am I just doing something really bone-headed?

Thanks,

Steve

Download File:post-14611-1233787311.vi

Link to comment

I generally use a single event structure for all of my user interface control. I use queues to communicate with the individual while loops which actually do the work. Remember, once you begin processing inside a case of an event structure no other event can be serviced until that one completes. Using multiple event structures complicates the control of your user interface and creates situations that you are seeing. A good practice is to have very minimal processing inside an event structure. Capture the event and trigger some other process (another while loop waiting on a queue or notifier) and then return to waiting for events. Off load your processing to separate parallel tasks rather than perform the processing inside of the event structure itself.

Link to comment

Your front panel is set to lock until an event as finished.

Uncheck the box at the bottom of your Event edition page. This is a useful feature when you want to prevent the user to perform any tasks while one completes, but in your case it's the reason why your panel is locked.

But I agree with Mark that you should rethink your program to have only one event case. I'd suggest three loops: 1- Event case for UI, 2- Camera and 3 - Motor.

This way you can act on your motor and camera via Queues or any other means of communicating between loops that you see fit. Your UI event case would thus be perfectly fit to be locked while you react to a user command, and your motor/camera will be separated.

Link to comment

QUOTE (GraemeJ @ Feb 4 2009, 06:21 PM)

Any suggestions on how this would used with a user interface which has

multiple tab pages, and different controls and indicators on each page?

Regards,

GraemeJ.

Within the single event structure you simply create event cases for each control or evnet you are interested in processing. This can be extended by using user events in addition to the standard events (value change, mouse up, mouse down, etc.).

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.