05-23-2007 10:22 AM
05-23-2007 10:39 AM
Hello,
When working with a single threaded application, only one control callback function can run at a time. Even timer callback functions will not be executed when another callback function is running. If you want to keep your application single threaded, you could use the GetUserEvent and ProcessSystemEvent functions, to prevent your application from freezing when executing long callback functions. But keep in mind that these functions will only return when their task is completed, and thus block your callback function for some time. If you really want to perform multiple tasks simultaniously, you should consider creating a multi threaded application. For more information, I suggest you read this article:
http://zone.ni.com/devzone/cda/tut/p/id/3663
Also, a lot of examples are available in the directory: C:\Program Files\National Instruments\CVI80\samples\utility\Threading
05-23-2007 07:26 PM
"only one control callback function can run at a time" I disagree with this statement.
We use a sequencer type GUI that runs the main test programs as well as we have a timer that fires every 5 seconds and talks to an ess chamber via a serial port to get the status(temperature,interval etc) of the chamber controller
and it works fine.
I think the reason the panel "appears dead" is because the callback that is running does not have any processsystemevents() functions in the code.
The processsystemevents() will allow other callbacks/timers to run.
look at http://forums.ni.com/ni/board/message?board.id=180&message.id=29421 for a demo of this program.
05-24-2007 02:52 AM
"only one control callback function can run at a time" I absolutely agree with this sentence wich really true. So true that a function is provided to launch parts of code that are to be executed after the caller has finished running (PostDeferredCall); this function is especially useful when the deferred code is long lasting and could interfere with the normal scanning of a timer or a repetitive task (interrupt).
In my opinion the stated sentence must be intended this way: "only one control callback function can run at a time unless you use ProcessSystemEvents () inside your functions". But you must be careful using this function, since you may run into unpredictable conditions if one callback is called out of time.
As an example consider this situation; a loop waiting for some external condition to terminate:
double t;
t = Timer ();
while (fase != 2) { // Wait for external condition
SetCtrlVal (panelHandle, PANEL_ELAPSEDTIME, Timer () - t);
SetCtrlVal (panelHandle, PANEL_FASE, fase);
ProcessSystemEvents ();
if (Timer () - t > 20.0) { // Timeout
// Perform some abort code
break;
}
}
While executing this loop the system processes all external events like timers and callbacks fired by user action on UI controls. Now suppose the user clicks on a button which is not allowed in this moment: you fire a MessagePopup () informing him to retry later. The popup message is displayed on the screen and all the rest of the program continues running, right? Wrong: your loop is blocked until the user presses "Ok" !! No external condition is monitored (even if the timer or the interrupt that could rise it is normally working) nor the timeout condition is handled!
Moreover, even if no such a dangerous condition is met, when you call ProcessSystemEvents () inside a function and there are events pending, your function is suspended until those events are processed, next it resumes working. And you must pay attention that no external callback called changes some variable that your original function is using!
That is, ProcessSystemEvents () indeed is a useful function but it must be used with extreme care!
05-24-2007 08:27 AM
For sure but you always must consider a callback to be a multithread application and be carefull about usage of global variables.
We have used ProcessSystemEvents() in callbacks for years with no problems as long as you follow the above.
Consider each callback a function that can be run at any time. If you press a button and you do not want any other button to be run(dim it)
so the operator can not press it. See my demo program above. It is our ESS sequencer.
As far as popup, yes if you are waiting for an "ok" from an NI popup, you are halted until OK is pressed.
We strive to make "automated" test programs so placing a "popup" in an "automated" test is counted productive.
05-24-2007 10:12 PM