Image Acquisition Blocks UI Execution

[Gerry_Ford]

I am currently trying to create a user interface that displays images from a camera attached to a microscope with a movable table.  The user is able to interact with the images, and can click on them, which causes the table to move to a new location.  Acquisition is done by calling a camera DLL, the point grey flycapture DLL, by using a call library function node.

When I am acquiring images at 15 frames per second, there are no problems with user input.  However, when I drop the acquisition to 2 frames per second (necessary if you need to have longer exposure times), labview seems to pause the UI while image acquisition is occurring.  UI interaction only seems possible in the holes between image acquisitions.

I am sure that this is happening because some sort of blocking is going on here.  The program is waiting for the newest image to be returned and will not allow anything else to happen while it is waiting.  I have the image acquisition running in a separate function, called from a higher level VI, that puts image data into a global variable (I know I know...global variables).  When I need to display the image, I read from the global variable and display it on my UI form.

I think that I need to run things in separate threads to avoid the problems that I am having because I have a dependency that is causing blocking.  I am looking for suggestions as to how I can architect this.  I have thought about using a VI server to launch the camera acquisition, and will try to implement this, but I'm wondering if there is another method that I'm missing here.

Any suggestions would be greatly appreciated!  I am using LabVIEW 8.6 on a Windows 7 machine by the way.  I am not using LabVIEW's image acquisition module.

Thanks

[falkpl]

do you have your call function configured in the UI thread?

[Gerry_Ford]

Paul,

Here's a little more info on how I have everything configured.  I have a master VI that runs all of my setup functions, image acquisition, and UI forms.  This VI calls the initialization functions of the stage and camera.  It opens the camera & initializes all of the memory the camera will need.  Then it starts acquisition.

From this point, I run a sub VI that grabs images from the camera and puts them continuously into a global variable.  This VI is not visible to the user.  My thought with this VI is that I want the images to be put into a location where I can access them to display them to the user, but I don't want to actually call the camera DLL from within my UI because I don't want the calls to block the UI.

After starting this sub VI, I then run my UI VI.  In this VI, I grab images from the global variable and update them at a fixed frame rate so that the user is seeing images at between 1 and 15 frames per second (depending on how I define the update speed of the picture control).  The problem occurs in this VI.  If I have the camera grabbing images at 15 FPS in my image grabbing VI, I have no blocking and no problems in my UI VI.  However, if I increase the exposure time on the camera to 0.5 seconds (thereby making the frame rate 2 fps), UI code will only execute after each new image is displayed.  I suspect the same thing is happening when I'm running at 15 fps, it just isn't noticable to an end user.

I'm not exactly sure what thread the call function is executing in as I don't define it.  I set the VI Properties of the VI that calls the grab image function to standard while I set the VI Properties of the UI VI to user interface.  This doesn't seem to fix the problem.  Additionally, I have tried setting all of the functions to "same as caller" with the same results.

I thought that the way I separated the acquisition of images and display of images in my program was sufficient, but obviously it is not.  So...any suggestions as to how I can further separate it?

[Paul_M. · Accepted solution]

Hey Gerry,

This is Paul in the applications engineering department here at National Instruments. What the other Paul was referring to was the configuration properties of the Call Library Function Node. If you right click on the Call Library Function Node you can click on Configure and you should see a window that looks like the image below.

As you can see, you have the option to select run this library in the UI thread or in any thread. This is important because there is only one UI thread. Consequently, deadlocks can occur when code is written in parallel but the operations are both occurring in the UI thread. What results is part of the code has to wait for the other part to finish and hence the lock up in the UI. Now, the reason why the Call Library Function Node is set to run in the UI thread by default is because only thread safe functions can be run in any thread. So before you go changing this configuration it is highly recommended that you verify that the functions you are calling are thread safe. You can also verify what configuration the Call Library Function Node is in by the color of the node itself. If it is a orange color that means it is set to Run in the UI thread. If it is a pale yellow color, it is set to Run in any thread. Let me know if you have any more questions!

Paul M

[Gerry_Ford]

Thanks Paul, that did the trick.  The program was waiting for the image to be returned before it could execute anything in the UI thread.  Now the thread safe verification begins...