Getting around commiting at task to hardware in DAQmx and maintaining HW timing when switching between two AI tasks.

[wwilbanks]

I have a project that requires two HW timed AI task that are triggered at different rising edges. I originally started with an example vi that has HW timed retriggerable AI that seemed to working fine until I decided to capture two channel with a seperate task. I received error messages due to the orginal task being committed to the hardware that prevented the second task for being configured due to reserved resources.

I was able to changed the commit to verify and switched from a analog edge trigger to a digital edge so I could use another PFI for triggering the second acquisition and the program seems to work fine at the momment.

Questions that I have are:

What exactly do verify, reseve and commit refer to in regards to task setup and impact on task switching delay. What information is actually transfered when configuring the task and what are the typical delay times for switching between tasks for the task controls listed above on a PCI6071e card. I am concerned that HW timing may have been sacrificed in order to work around the reserved resources and that if someone bumps the mouse the timing sequence will miss a trigger due to an IRQ.

Any information on this topic would be greatly appreciated.

Kindest Regards,

Bill

[McKala[DE]]

Hi Bill,

Are you trying to sample both lines at the same time or are you just interested in sampling them one at a time? 

Verify is the driver checking the configuration for accuracy, reserve is reserving resources, and commit is programming the hardware.  You can only run one task at a time because all the channels are multiplexed to the same A/D and each task reserves the A/D.

In order to sample two AI channels at the same time, they both must be included in the same task.  While you cannot have two different triggers for the same task, you should be able to do some post acquisition processing on your data. 

If you only interested in sampling the lines one at a time, then you can use two different tasks.  The time it takes for one task to release the reserved resources, return to the verified state, and for the second task to reserve the resources and commit the task is completely system dependent.  If you have to use two separate triggers for the two channels and you cannot process the data later, you will have to get a board with multiple A/D's. 

Good luck with your application,

[wwilbanks]

Micaela,

Thanks for the information.

What I have are two trigger timing signals for the AI tasks that capture data at different times(Tdelta = 550 us) within the waveform period. One AI task is setup to capture two control signals that provide a sanity check to verify that the data captured with the second AI task is correctly correlated with the control signals. The second task captures 14 NRSE channels of data on the outputs of the DUT. I believe the problem lies with the software stop required for analog triggering and subsequent reconfiguration of the next task.

I was out yesterday and learned this morning that the vi is only capturing about 20% of the actual cycles that the DUT is seeing. Interestingly, even the single 14 channel committed task was only capturing 60%. I need to see if I have some delay timers in the while loop in which the data is collected that could impact the loop the execution and mess-up the whole timing sequence.

Onel last question: Can these two task be configured into one single task that contains two virtual channels of different # of channels , AI range and indepedant triggers for each that can then be programmed into HW with the commit setting? It does not hurt to ask, but I may not like the answer.

Kindest Regards,

Bill

[lrallen]

Bill,

Unfortunately, you will not be able to combine these channels and have independent triggers.  Any trigger configured for a task will apply to the whole task.  Also, as Micaela stated, you not be able to simultaneously run two different tasks of the same type on the same board.  The best way to get this type of independence would be to get a second daq card.  This will give you the ability to independently trigger two analog tasks and acquire from them at the same time.  I hope this helps!

Regards,

Lon

[wwilbanks]

Lon,

Thanks for  the reply. I have another related question in regards to configuring the read property node for a digitally triggered start-stop routine with 2 presamples and collecting 5 samples per channel on 14 channels. Triggering occurs at 500 Hz and the total sampling time for all channels is restricted to 500 us max. I am current dealing with a single AI task and having difficulty capturing all the data in an output file. I have tried using a large array to store the data until the test is complete then write the array to a file to see if the file I/O was the problem. It did not work.

I have looked the the vi and information with respect to "How do I use digital triggering to start and stop AI". The description included with the vi indicates that the read property "Relative to" must be set to current read position and the buffer definition modified to something hugh in order to keep the ahead of the write. I have tried this and cannot seem to capture the correct number of bytes in the output file. I have tried different "Relative to" settings and offsets with no luck.

A quick summary of the test is 1000 cycles with 5 samples per channel on 14 channel captured twice during each cycle. Data read as I16 (2bytes). Neglecting the 300-500 bytes in the test comment header,  the file should be in the 112k range (1000*5*14*2*2). When I do happen to collect some data the file size is either way too small or much larger than expected.

All this information to ask the simple question; How do I configure the read properties to make certain that I collect all the data and store it in a file.

I apologize for running on about this problem, but I am getting really frustrated with this.

Kindest Regards,

Bill

[lrallen]

Bill,

There are not really any "read properties" to guarantee that all collected data is written to the file.  I would take a look at the Cont Acq&Graph Voltage-To File(Binary).vi and Graph Acquired Binary Data.vi to see how to correctly write data and then also how to read that data back.  Maybe you could modify them to see if you can get all of your collected data to the file.  I hope this helps.

Regards,

Lon

[wwilbanks]

Lon,

I have an application where I have already utilized the approach you mentioned in the example. However, this application does not require a continuous capture as is used in the example vi, but rather periodically sampling the device output conditions after my actuation signal changes the device state. It is the periodic sampling and subsequent read /write to disk that is the root of the problem as I am already writing the data to the output in binary (I16). Unfortunately, only 60% of the data is actually in the file which suggests that there is sufficient delay in the loop that causes the card to miss some triggers. Your guess is as good as mine as to which triggers were missed.

Thanks anyway.

Regards,

Bill

[lrallen]

Bill,

Perhaps if you post a simplified version of your application which exhibits this behavior, I could take a look at it.  Have a great weekend!

Regards,

Lon