async timer creation

[menchar]

If I create an async timer "disabled", do timer ticks accumulate anyway so that when the timer is enabled, callbacks are generated for all of the accumulated ticks?

If so, why would you ever want to create an async timer "disabled" - it just doesn't make much sense.

I'm looking for behavior like a regular timer when it comes to enabling / disabling the async timer - but it looks like my only option is the actually discard the async timer and re-create it in lieu of enable / disable, since ticks will accumulate and the callback will get called continuously until the accumulated ticks are exhausted.

Thanks for any insight into this.

[jr_2005]

According to the Asynchronous Timer Help for the attribute ASYNC_ATTR_ENABLED, if the timer is disabled then any callback triggers are missed - that is, they are not queued up. Just like the normal Timer control, really.

JR

[menchar]

JR -

That's not at all what I am seeing in the help for the Async Timers instrument panel in CVI 2009.

"setting ASYNC_ATTR_ENABLED to 0 causes timer events to accumulate until you call ResumeAsyncTimerCallbacks or set ASYNC_ATTR_ENABLED to 1.  When you resume timer callbacks or enable a timer, the previously running timer begins generating events as quickly as possible in order to dispatch the accumulated events."

Menchar

[ngay528]

I can confirm was menchar has seen in which it is not clear on how to stop processes from accumulating.  

In the help portion of "SuspendAsyncTimers" it says:

Note  SuspendAsyncTimerCallbacks does not disable timers. If you want to disable a timer, rather than suspend it, set the ASYNC_ATTR_ENABLED attribute to 0.

in the help of SetAsyncAttribute for Enabled, it says:

To disable the timer, set ASYNC_ATTR_ENABLED to 0. Setting ASYNC_ATTR_ENABLED to 0 and then back to 1 does not disturb the ongoing interval schedule... Suspending timer callbacks or setting ASYNC_ATTR_ENABLED to 0 causes timer events to accumulate until you call ResumeAsyncTimerCallbacks or set ASYNC_ATTR_ENABLED to 1. When you resume timer callbacks or enable a timer, the previously running timer begins generating events as quickly as possible in order to dispatch the accumulated events. The interval at which the timer generates events might be shorter than the interval you specified when you created the asynchronous timer. When the timer finishes dispatching the accumulated events, the timer resumes generating events at the interval you specified.

So these are conflicting!

I wasn't sure what does happen, so in my program, I just set a locked variable and have a big if at the beginning of my async function.  One could also just delete and create a new one each time.

[menchar]

The NI example for async timers does only create and then delete async timers, it doesn't try to suspend callbacks or disable an async timer.

I seem to recall going down this rathole several years ago, but I couldn't find anything on it in the forum.

I hate when this happens - your only choice is to either run experiments to see what NI actually implemented, or just hope somebody on the forum knows.

I believe the sources for async timer may be available, and it could be that the behavior is due to the Win32 media timer semantics which NI used to implement the async timer.  If so, it's not NI's fault and I take back what I was thinking about them

Menchar

[LuisG]

We'll have an answer for you guys on this issue, but it'll probably take a few days until we can get to it. Bear with us.

Luis

NI

[menchar]

I believe I'm seeing async timer callbacks accumulate and then get invoked in rapid succession once they are again able to be dispatched.

I think this is in keeping with the idea that an async timer is an "important" timer that runs on its own thread and that async events should always be invoked, even late, rather than thrown away.

The media timer is the root cause I bet.

Menchar

[Jeff_P.]

The help for async timers was updated in CVI 2009. Ironically, I was making an honest effort to better document some of the non-obvious behaviors of the async timer and in the process I got the documentation wrong.  To be clear, there was no change in async timer behavior in CVI 2009- only the help was changed.

The updated CVI 2009 help is incorrect about timer tick events always accumulating when the timer is disabled or suspended. Async timer tick events can indeed accumulate and be dispatched rapidly in an attempt to catch up, but this behavior is triggered when the library thread responsible for calling an async timer callback gets behind because an async timer callback is taking too long to complete.

For example, consider a single async timer running at an interval of 50 milliseconds. If one particular call to the async timer callback took say, 200 milliseconds, then the async timer could fall behind by 3 iterations. In that case, the async timer would dispatch those 3 make-up ticks in rapid succession in order to catch up. The processing of those make-up iterations might cause the timer to fall behind a little further which would result in the same catch-up behavior until the async timer was back on schedule.

On Windows, things are slightly more complicated because all async timers share a single thread to dispatch timer tick events. In addition to the single async timer scenario described above, there can be additional issues where the duration of any async timer callback function can have an impact on all other async timers. For example, assume we have one async timer with an interval of 500 milliseconds and the callback function takes 200 millisecond to finish and we have a second async timer with an interval of 50 milliseconds that takes 10 milliseconds to finish. When the first async timer fires, the callback will run for 200 milliseconds which will block the execution of the second async timer which should fire every 50 milliseconds. This will cause the second async timer to accumulate multiple timer tick events which will fire as fast as possible after the first async timer callback finishes. The second async timer will then resume firing timer ticks at its regular 50 millisecond interval until the next time the first async timer fires.

Thanks for bringing this mistake to our attention. We will correct the documentation. Sorry for the inconvenience.

-Jeff

[nantek]

Hi Jeff,

Is there anyway that one can create the async timers running in their own thread instead of sharing a single thread?

thanks

[ngay528]

To extend on the previous question, would it be more worth while to just have a separate thread with a sleep (Delay) state.  Obviously the total elapsed time is the delay plus time of execution.

Nick