LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

CVI 8 Lockup when manipulating RING Control

I'm experiencing lock-ups on my application during a particular circumstance.
 
My application collects and plots data from a spectrum analyzer using GPIB. The panel has an Graph control where the data is plotted, and a Ring control where I store the names of plots that have been saved.
 
When selecting a different plot using the ring control, EVENT_VAL_CHANGED envokes a subroutine that loads the data from a DiaDem file and plots the data to the graphic.
 
The program also has a positioning controller for an antenna that is GPIB.  When the software commands the positioner to move, it calculates how long it will take for this motion to complete and sets a timer to this value.  When the timer expires, the software checks the position of the controller and sets a flag to allow the process to continue.  It executes this in a loop so that the program essentually waits until the motion is complete.
 
i.e.:
 
SetWaitCursor (1);
SetSpeed (2);
SetPositionerTimer (Speed2);
while (!PosMoveComplete)
{
     ProcessDrawEvents ();
     ProcessSystemEvents ();
}
SetSpeed (1);
SetWaitCursor (0);
 
The timer subroutine will set the PosMoveComplete flag when it sees that the positioner is in place.
 
OK...
 
So the problem that occurs is when the user clicks on the Ring control and activates the dropdown menu. If the dropdown is visible at the same time that the software commands the positioner to move, the software will lock-up. When changing windows, the pulldown is always visible on top of everything else.
 
During debug, breaking execution show that the process is stuck in the loop because the flag is never set. I found that the GPIB command is never actually sent to the controller, although it does show up in GPIB Spy.  Additionally, although I'm enabling the timer in the SetPositionerTimer subroutine, the timer callback never executes.  So I stop the program, and when I restart it, as soon as the GPIB bus to the controller is initialized, it moves to the position it had been previously commanded.
 
I can also simulate this problem by manipulating other controls on the panel at just the right time, but the Ring dropdown menu being visible is the easiest.
 
Sorry for such a long post...
Any ideas on where I should look to resolve this problem?
0 Kudos
Message 1 of 2
(2,884 Views)
The interaction between ProcessSystemEvents and some ongoing UI actions, such as operating a menu or a button (commonly referred to as "tracking loops") is a bit tricky to explain. Suffice it to say that it can result in apparent hangs, since depending on which action happens first, one action might be nested inside the other. It looks as if you ran into such a situation. You can review this post from Bilal that discusses it in more detail.

The typical workaround for this problem is to use a different thread for your timer as you do for the UI. A quick way of doing this without having to program the threads yourself is to replace your UI timer controls with a timer from the asynctimer library (toolslib\toolbox\asynctmr.fp). These timers call your callback function in a separate thread, so you won't have these deadlocks. One thing to keep in mind, however, is that when you have multiple threads running at the same time, you'll have to be careful with global data that both threads access. If all you have is the PosMoveComplete flag, you should be ok.

Luis
NI
0 Kudos
Message 2 of 2
(2,867 Views)