AI scanclock sleep mode--labv​iew RT

Question

I've been using AI single scan in a time critical loop, with 0 buffer, to
sleep on the AI Scan Clock. Everything seemed to be working real nicely
(i.e, all of my lower priority threads seemed to be serviced correctly),
until I started trying to do hardware calls in lower priority threads to
"check" to see how long it took to service low priority threads by
initiating counter pulses at the onset and offset of these loops (there
seems to be no other reliable way to get this information with tens-of
microsecond resolution). All went to hell then. When I slowed down my
loop to try to use more "software" type sleep modes instead of the AI
single scan sleep (that is sleeping for milliseconds), everything seemed
to work again.
A
s we started delving in to see about different types of sleep modes, we
noticed that there is a small paragraph in the "counter wait" sleep mode
documentation that says while the time critical loop is asleep from a
counter wait, NI-Daq calls cannot be made. This would explain the
behavior I'm seeing (i.e, "all went to hell").
In any case, there is nothing in any of the development areas or
documentation stating that NI-Daq calls are not serviced while the time
critical loop is asleep due to AI Single Scan waiting for the AI scan
clock. It seems quite reasonable that this is the case, though, and it
makes sense to keep all your hardware calls in the time critical loop
(though I tried to violate this rule for testing purposes, and in fact
sleeping on a ms wait does allow such calls!). I just hadn't seen the
counter wait documentation because I'm not using the counter wait.
Long story short, are NIDaq calls serviced during an AI Single Scan
sleep? If not, can this be a
dded to the documentation where this type of
sleep is described?? This cost us about four days (though I probably
deserve it for making hardware calls in low priority loops!).
Thanks
Scott
Reverse first field of address to reply

Answer 1

Hello Scott,
The behavior you are seeing is expected and is due to the fact that the NI-DAQ driver is a single-threaded DLL. For more information I would check out the following NI Developer Zone article:
Avoiding Shared Resources and Priority Inversions for Deterministic Applications
While we try to get as much useful information in the manual as possible, we always recommend checking out the NIDZ for good additional information.