LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Help needed with cvi Timer

I have a multithreaded application where user clicks on a control button in the main uir (main thread), a new thread is created which loads a new panel with it's own cvi timer automatically enabled.

In certain situations, all timer in the active thread has to be suspended so i created a loop which will post a deferred call to the thread to suspend the timer.

After that, if i were to terminate the thread (discard panel) and reload the same function, the timer does not work anymore. why? (sometimes it works but more often then not it doesn't)

Any advice would be more appreciated.

Thanks

Cheers
AL
0 Kudos
Message 1 of 6
(3,847 Views)
Add on..

i seem to have isolate the problem. Some bug i think. It seems that the thread remembers the state of the timer (suspend), independent of function, even after "CmtReleaseThreadPoolFunctionID".

If i were to load a new function using that thread from the same pool, the timer will not work.

Guess i have to call "ResumeTimerCallbacks" before running any of my functions or is there a better way??

Any advice appreciated.

Cheers
AL
0 Kudos
Message 2 of 6
(3,843 Views)
Hi Al,

I have not been able to find any reports of similar behavior. Calling ResumeTimerCallbacks seems like a reasonable workaround. If you have a small project which demonstrates this behavior I would be happy to submit a report to our R&D department. This will allows us to determine if this is a bug and if so, address it in a future release of CVI.

Scott Y
NI
0 Kudos
Message 3 of 6
(3,814 Views)
Hi Scott,

i have modified the Multipanel sample project shipped with CVI which demonstrates the problem i encountered. I have also included the test procedure in the project itself.

Do let me know on the outcome. Thanks.

Regards
AL
0 Kudos
Message 4 of 6
(3,805 Views)
Al,

I ran your program and it is working as expected. When you call SuspendTimerCallbacks and ResumeTimerCallbacks, those functions affect all the timers in the entire thread. Its effect persists for the lifetime of a thread. And as you can see when you look at the thread ids, the same thread "survives" from one function to the next. That's why thread pools are used: so that they can cache system threads, thus improving performance.

In your test program, you asked: "I thought when you load a new panel it should be the default settings." When you load a panel, all the settings of the panel and its controls are indeed set to their default state. The problem here is that the suspend/resume state of the timers is not a panel or a control setting -- it is a thread setting, and therefore will last for the lifetime of that thread.

If you want to suspend and resume timers on a per-timer basis, you can use the ATTR_ENABLED timer attribute instead. This will certainly be reset for each new timer that is loaded/created. Another benefit of doing this is that in order to suspend/resume you don't have to post an event to each timer's thread. You can set this attribute, for any timer, from the main thread.

Alternatively, calling ResumeTimerCallbacks at the start of each thread function is also an acceptable solution.

Luis
NI
Message 5 of 6
(3,782 Views)
Hi LuisG,

thanks alot, this has made it alot more clearer to me. i suspected it was something like that but didn't understand why.

using the ATTR_ENABLED attribute sounds good but the downside is i have to know the panelhandle, the control name before i can suspend it and not all panels may be loaded when i want to suspend the timer.


Guess calling ResumeTimerCallbacks is the only way out that i can use.

Thanks once again.

Regards
AL
0 Kudos
Message 6 of 6
(3,768 Views)