ReadCounterScalar Timeout error

[MikeD@schaeffler]

This is a gerneral application for all(20+) of our test stands.  It has all the I/O built into it and reads a configuration file to determine what I/O is being used.  The current configuration sends an analog command signal for speed, while watching the encoder feedback to ensure it has reached the commanded speed.  It is also monitoring analog signals for temperture and vibration.  The configurations is also set to log and command at 100Hz.  With a timeout of .08 seconds 100Hz is not possible.  This timout is causing my command values to not be a linear ramp(3200rpm/s) from 0 to 700 rpm.  

Like I stated before this application worked previously with Traditional DAQ, but the DAQ portion of the code was updated to DAQmx so that we could switch to Windows 7.

Yes I had tried different timout values and the funtion would always have issues with not holding to the timeout I specified. 

[Patrick_NI]

Hello MikeD, 

I think you are misunderstanding the purpose of the timeout of this function.  A timeout should not be used for any timing consiterations, rather, it should be the maximum amount of time allowed for a function to complete.  So, if you set the timeout to 10 seconds, it will still operate in the minimum amount of time to complete the function.  The reason the function is taking more time than that is likely because there is a minimum amount of time for the timeout to occur.

Going forward, here is a resource for how to convert TDAQ applications into DAQmx applications: http://www.ni.com/white-paper/5957/en

Additionally, there is a beta driver for TDAQ in Windows 7.  However, since it is a beta driver it is not supported or guarenteed to work.  this driver is found here: http://digital.ni.com/public.nsf/allkb/8EC9E81C3DE4E619862573930083BD7A

[MikeD@schaeffler]

I understand what the timeout is for.  I was just clarifing how it is effecting my application run time.  My main timer tick is set to 0.01 seconds which allows me to read and write to my DAQ card at 100Hz.  I have my timeout set to 0.002 which allows it to read two pulses or a speed of around 60 rpm.  If  my application sits on this read counter funtion for 0.08 when I tell it to timeout after 0.002,  then it is the fault in the function that is determining the timing of my application not my timeout.

[Patrick_NI]

There is a minimum amount of time that will work as a timeout for this function.  When you put 2 ms, the function still takes time before it checks for a timeout.  If you want the minimum amount of time to read the counter, try putting the timeout as "0".  This will try once to read the requested samples. If all the requested samples are read, the function is successful. Otherwise, the function returns a timeout error and returns the samples that were actually read.

[Mande]

I know this is an old discussion but I am now experiencing the same thing.  Actually this is not the first time either, struggled with this before.  Actually my situation is very similiar, updating an older TDAQ system to using NIDAQmx.  The original was not realtime OS, it was possible because we had more control over the chip with traditional DAQ.  Now all we can do is ask for the frequency.

As the original poster said, you pass a timeout to the function, and it doesn't work.  I have also used 0.0 for the timeout and the function takes 15ms.  I have tried many different values and it simply does not affect the amount of time spent in the function.  I am also trying to sample AI channels as well as this counter at 100Hz.  So far I have had to put my two counter reads into seperate threads and read them at 40-50 Hz because of this.

We would like to know why the function doesn't respond to the timeout value.

Thanks.

[MikeD@schaeffler · Accepted solution]

The following is the answer I got from NI.

"After having researched and looking into this service request, I have found an answer and explanation for this behavior we are seeing with this DAQmxReadCounterScalarF64. Now this behavior that we are seeing with the timeout is actually expected, and I will do my best to explain this:

Software read functions poll from a hardware buffer, as in the card is constantly clocking in data, so regardless of when you read in software, your data is still being captured at the specified rate that you want. When you call a read, the function blocks the thread on which it is executing until the read completes or times out. Windows manages when this function is able to poll the driver for available samples and to check if it has timed out.

If the function is only able to check whether it has timed out 12 times per second, then the 2 ms timeout will throw an exception after a twelfth of a second.

Now if you have time critical code that for instance needs to run 100 times per second, then you may want to consider a producer/consumer architecture. This will allow for you to do software reads from your hardware buffer at an arbitrary rate, and push the samples into a software queue. Then the consumer would then read off the queue at 100 times per second.

Ultimately, I would recommend real time as a solution if you need better than 50 ms timing resolution and stability. Real time will let you control loop execution rates in microseconds. Your read function's poll rate will likely exceed 1kHz, allowing it to throw a timeout exception at a time much closer to 2 ms after the read is called."

"This issue with the timeouts comes down to the operating system that the code and CPU architecture (single core vs. multi-core) is being run on. If you have had success in the past with running this code on a XP machine, then I would suggest to continue using this environment.

The change in execution time here is evidence that Windows is not the best approach for the requirements. If you want to use this code and reliably have around 100 iterations per second, then I would suggest looking into LabVIEW Real Time applications. "

I ended up creating a second thread for this function so that it did not hold up my time critical application.

[Mande]

Hi, thanks a lot for the reply!

It is unfortunate that we lost control of such things going from traditional NIDAQ to NIDAQmx as I am able to read quicker on a Windows 7 computer using GPCTR functions in traditional NIDAQ.

But in any case, I did the same thing and created seperate threads for these functions.

Now I have to figure out why it randomly returns a frequency value double of what is actually being applied.