NIDaqDelay Crashes the program

[LLiu 81]

I have several e-series cards, and I need to introduce long (8 seconds) and short (0.5 to 1 second) delays in my programs on Win XP machines. I found that if I use NIDaqDelay function, the program crashes in an unpredictable way. For example, the following loop
For i=1 to 100
r=NIDaqDelay(8)
DoEvents
Next i
sometimes crashes at the 35 round, sometimes at the 80 round, and sometimes crashes at the beginning. If I used 1 instead of 8 seconds, my chance of crashing the program is reduced, but I still cannot eliminate the problem. NI's user menu says that NIDaqDelay does not use any DAQ hardware. What does it use? Does it use the clock in the computer? In the VC++ forum, somebody suggested using Windows' sleep function. However, if
NIDaqDelay is just a call to sleep, then why it crashes all the time? What is the resolution of NIDaqDelay, 1 millisecond? As far as I know, sleep (or GetTickCount) has a nominal resolution of 1 millisecond, but it is very unreliable unless the delay is in the order of 200 milliseconds or more. Is there a simpler and more reliable way in NI-DAQ (with an e-series card) to introduce long and short delays? An example or sample code would be appreciated.
Lei

[JaredA]

Hello Lei,

It looks like you may have already done some research on this issue and I appreciate that. NIDaqDelay is a utility function that was first provided with NI-DAQ 5.0. They are provided in DLL form such that they can be called from just about any Windows programming language. Furthermore, this function call utilizes no hardware.

The instance of NIDaqDelay causing some problems when called inside of a loop has come up before in the past. Since the release of these provided functions, the development and support of them has been significantly reduced and removed as NI-DAQmx has no use of them. The issue has been brought to the attention of our development teams, but the only information that they were able to derive is that the crashing/freezing iss
ue is system dependent. Some machines would experience the problems whereas others would not. The only reliable answer that NI is able to provide is that the Windows SDK Sleep function should be used instead if you are experiencing this problem. I was able to find another discussion thread which is directly related to your own. You may find that here. Regardless of resolution, any type of function call that you are relying on for timed operation will not be as accurate as you want since you are most likely working in a non-real-time environment.

I hope this information helps.

Jared A

[LLiu 81]

Thanks, JaredA!
I calibrated Windows' Sleep or GetTickCount. They are not very precise. The nominal delay and the actual time interval is not a continuous function but a step one. Such errors become unacceptable for shorter intervals (<100 milliseconds), because sometimes the error can be 50% of the nominal delay. Besides, the delay is likely to be influenced by the machine used and the number of concurrent programs running on the machine. Since the E-series card has a general purpose counter, I wonder if that can provide a more precise delay of the program. If so, can you give me a hint what I should do? Code samples will be appreciated.
Thanks.
Lei

[JaredA]

The code that I am going to refer to you should be installed with the version of NI-DAQ that you have. The examples are located at \Program Files\National Instruments\NI-DAQ\Examples\. For your particular instance, it would be \Examples\VisualC\Ctr\. You can consider trying to take advantage of Simple Event Counting (STCeventCount). Simple event counting will merely count the number of edges that come in on the source of the counter. When the counter reaches the terminal count (the count rolls over), you can configure the output to toggle. I also believe that it might be possible to monitor the state of this toggled output. You will want to refer to the Traditional NI-DAQ Function Reference Help located in Programs > National Instruments > NI-D
AQ in your Start Menu to learn about the different NI-DAQ functions that are available and what they can do.

Another thing you should look into in the Traditional NI-DAQ Function Reference Help is DAQ Events. I am not a large advocate of DAQ Events, but you may find them helpful in your application. DAQ Events notifies Traditional NI-DAQ applications when the status of an asynchronous DAQ operation (initiated by a call to DAQ_Start, DIG_Block_Out, WFM_Group_Control, and so on) meets certain criteria you specify. Notification comes through the Windows PostMessage API and/or a callback function.

Anything that you do, you are going to find the result to not be as accurate as you are hoping. You are operating in a non-real time environment. The time something executes in the processing queue and then gets updated for another action to take place is system dependent. You might just have to come to the realization that you'll just have to take what you are already seeing. Ideally, you
would want to be working with an API and OS that would allow you to operate in a real time environment.

Jared A