ASYNC_ATTR_TIMER_TIME

[menchar]

If I have an async timer and it's making callbacks to a function that stalls, if another thread were to check ASYNC_ATTR_TIMER_TIME would this async timer attribute value been seen as failing to increase?  I.e., with postponed callbacks queueing up (due to failure of the callback to return since it's stalled) does this attribute value continue to increase with enqueued callbacks, or does it stop increasing until a successful callback is made?

I.e., how do I determine if an async timer callback has stalled?  I can't easily check on the async timer thread, since it belongs to the OS or the CVI runtime it would seem.  Maybe the first time the callback runs it gets the thread handle and then a second thread can use the handle to check on the thread.

I have an async timer callback that's stuck in an endless loop, inside the CVI serial library somewhere I think.  I'm doing an OpenComConfig on a virtual serial port (implemented in a DALSA framegrabber/DALSA DLL) within the callback, and it looks like it is getting locked up and not returning.  One of the CPU cores shows 100% utilization, I can't tell which thread is in it but I have good reason to belive it's the async timer callback - the process's CPU time shows full utilization.  I've had nothing but trouble using the CVI serial library with the DALSA virtual com ports - can't tell where the problem is, in the serial library or in the virtual com port.  I've eliminated com callbacks, I've output byte by byte with delays in between, increased timeouts, etc. etc.   Seems sensitive to queue sizes, timeout values, whether any UART lines were set ... it's been a real pain.

Thanks.

[Renée]

menchar,

To answer your first question, try creating a sample program in CVI which makes the callback to a function in a continuous recursion loop. Put a breakpoint in the loop. Make sure the function you are calling does some actions, which will also help you monitor the flow of your project. This way, you see that the loop is trying to loop fast while the timer which you are using will hold it back. By using the breakpoint, you will be able to tell if the loop waits for the return, or if it continues 'sending' the callback (ie if a stall occurs).

For your other question, place a variable to be increased at the beginning of the function which the callbacks call, and at the end of the function just before the return. By using these counters and knowing how many callbacks you make to the function, you will be able to determine how many times the function starts and how many times it returns. This should help you troubleshoot for your second set of questions.

[menchar]

I well imagine I could create an experiment to figure this all out, but I thought there might be a chance, seeing as how National Insturments implemented the software, that someone at NI might know how ASYNC_ATTR_TIMER_TIME works. 

Perhaps I didn't state the problem clearly - I know the callback has stalled, and may stall, as a result of normal operation, and I want to programmatically discover that from another thread.  The question is, does the ASYNC_ATTR_TIMER_TIME value increase as a result of a successful callback invocation, or does it simply increase every time it enqueues the callback, whether it is returning or not? 

It is true that I could have the callback increment a global each time it runs and I could check for that value failing to increase.  But, globals are non-preferred in general, and it looks like the async timer SW may have a built-in facility that might be used for this - ASYNC_ATTR_TIMER_TIME.

[Renée]

menchar,

The description for ASYNC_ATTR_TIMER_TIME can be found here: https://www.ni.com/docs/en-US/bundle/labwindows-cvi/page/toolslib/async_attr_timer_time.html

To determine if the incrementation of the ASYNC_ATTR_TIMER_TIME value is done during the callback enqueue or the callback invocation, you could use variable to count at either place and monitor these values, as discussed before.

Although globals might be non-preferred, this method would help you troubleshoot to determine which indicators to place in your code to flag a 'stall'. Once you've determined this, you could simply have a value set when a stall occurs, and pass a flag to your various functions to indicate a stall.

[menchar]

I give up.

[Renée]

menchar,

I'm sorry you feel that way. I would like to continue answering your questions for you, although I do want to set some expectations. As part of the National Instruments Applications Engineering team, we strive to help our customers be successful through answering questions and helping troubleshoot when problems arise in a project. If you would like a packaged project, navigate to the National Instruments Alliance page, located here, and you should be able to find what you're looking for.

We also have a support page, located here, where you can find tutorials and learn more about specific features of our various software.

[Renée]

menchar,

Walking through my previous instructions did give some descriptive results. After creating an Async Timer that displays a message on every callback, except the 2nd time through where it would delay for 7 seconds to simulate your 'stall', a second thread was created which would take the Async Time attribute and display it.

As a result, it turns out that the Async timer only updates when the callback runs. However, it does queue the new events when the timer ticks are missed. After the 'stall' completes and the code returns, the queued timer tick events run.

I hope this helps with your project.

[LuisG]

Hi menchar,

Let me just expand a bit on what Renée has said.

As you know, oftentimes, several of us CVI developers answer questions here in the forum whenever we know the answer right away. Even when we don't know the answer, if we're not too busy at the time, we'll run some tests or "look under the hood" to find out what the answer is and then answer it.

However, there are also lots of times when we don't know the answer right away. Even though, as you correctly pointed out, we might have implemented the feature ourselves, that might have been 10-15 years ago, and we simply just don't remember all the details any more. Or, in some case, the feature was implemented by someone who is no longer available to answer questions. We might have an inclination of what the answer might be, but it's probably not the best idea to tell you something that you then are going to rely on, unless we're pretty sure of it.

What Renée is trying to say is that, oftentimes, in order to find out what you want to know, any one will have to run the same exact test that you yourself can do.

From your point of view, I completely understand why you would ask questions here. There's a pretty good chance that someone might already know the answer. I definitely don't want to discourage you from continuing to ask these questions. That's what the forum is for. But I just want you to know that, if you don't get the precise answer that you're looking for right away, it's probably because no one really knew the answer right away. It happens.

Luis