Driver Development Kit (DDK)

cancel
Showing results for 
Search instead for 
Did you mean: 

Stopping a currently running DAQ task for m-series

I'm running a hardware timed analog input data acquisition task on a PCI-6229 m-series DAQ card that takes 200 us.  Every 250 us the program reads the data and restarts the task.  The difficulty is that the program sometimes has a late start and the next time the thread reads the task is still in progress.  I'd like to guarantee the task is stopped every time the program reads the data.  I've tried the following three sets of commands when the thread wakes up:

Attempt 1:
if( board->Joint_Status_2.readAI_Scan_In_Progress_St() )
{
     board->AI_Command_1.writeAI_Disarm(1);
     board->AI_Command_1.flush();
}

Attempt 2:
if( board->Joint_Status_2.readAI_Scan_In_Progress_St() )
{
     board->AI_Status_1.setAI_STOP_St(kTrue);
     board->AI_Status_1.flush();
}

Attempt 3:
if( board->Joint_Status_2.readAI_Scan_In_Progress_St() )
{
     board->AI_Mode_1.setAI_Start_Stop(kTrue);
     board->AI_Mode_1.flush();
}

They seem to randomly work.  Sometimes the task stops immediately, sometimes it reads a few more times, and sometimes it just keeps reading.  The positive part of these commands are that the task can be restarted by simply issuing the aiStart(board) command again -- most of the time.  Is there something that I can send to the card to reliably stop any currently running AI tasks and at the same time allow the aiStart(board) command to be used to start the next set of readings?

You may ask why I'm doing this.  I've had a lot of problems losing track of the inputs after 13 hr to several days at 250 kHz.  By restarting the task every loop and clearing the DMA buffer, I can guarantee the first element in the buffer is the first input read.  I'm using DMA so if the task is still running when I send the aiStart(board) command, it can screw up this balance.  You may argue that I should keep track of things more closely, but this system means that if the inputs somehow become switched the next time the thread runs it will automatically correct the problem.  This self-correction is a critical feature.

Thanks.



Aaron
0 Kudos
Message 1 of 2
(6,741 Views)

Hi Aaron-

The bitfields you attempt to write are problematic for a few reasons.  First, AI_Disarm is only safe to use for idle counters and may not work reliably if the acquisition is currently running (which it sounds like you have observed).  AI_STOP_St is a read-only bit, so writing it will have no effect.  Finally, AI_Start_Stop controls an unrelated functionality (essentially, it decides whether an AI_Start -> AI_Stop cycle constitutes a "scan".  This is actually the only mode of the STC2 that makes much sense to use on M Series).

There are a couple of bitfields in AI_Command_2 that might help.  AI_End_On_SC_TC is a strobe bit that disarms the AI_SC, AI_SI, AI_SI2, and AI_DIV counters when an SC_TC event occurs.  AI_End_On_End_Of_Scan provides the same functionality for when an AI_Stop occurs.  So basically, you could determine a regular interval boundary number of scans to stop on (using End_On_SC_TC) or just stop at the end of the "current" scan (using End_On_End_Of_Scan). 

I haven't tested this, but it should work.  Let me know if you have problems using either of these methods.  Hopefully this helps- 



Message Edited by Tom W [DE] on 03-14-2008 03:21 PM
Tom W
National Instruments
0 Kudos
Message 2 of 2
(6,581 Views)