Latency between Acquisition and Generation start

[emvee]

We are using a NI-PCI 6541 HSDIO card for simultaneously generation and acquisition of data. For this, we use some C code that is largely comparable with the DynamicAcqAndGen-SourceSynchronous.c example code and this does work okay. One thing that surprises me however is the long delay between the moment the acquisition is started and the generation is started.

The code I used to make the measurement is (somewhat stripped):

niHSDIO_WriteNamedWaveformU32( TxSession, TxWaveformName, read, buffer );
niHSDIO_ConfigureWaveformToGenerate( TxSession, TxWaveformName );
niHSDIO_CommitDynamic( TxSession );

QueryPerformanceCounter( (LARGE_INTEGER *)&before_acquire );
niHSDIO_ConfigureAcquisitionSize( RxSession, SamplesToRead, 1 );
niHSDIO_Initiate( RxSession );
niHSDIO_Initiate( TxSession )
QueryPerformanceCounter( (LARGE_INTEGER *)&after_generation );

double usec = after_generation - before_acquire;
__int64 nHPFrequency;
QueryPerformanceFrequency( (LARGE_INTEGER *) &nHPFrequency );
usec = 1.0E6 * usec / nHPFrequency;
printf( "%.0lf us between starting acquisition and generation started\n", usec );

And the typical results is something like 20000us = 20ms.

When I look into the captured data and see when data that is being generated caused a response in the acquired data, I see that this typically translates to something like 115000 samples, which translated to 2.6 ms on 45 MHz generation/acquisition frequency.

Combining these results, it seems to me like setting up the acquisition takes about 17.5 ms and starting generation about 2.5 ms. Both the 17.5 ms and the 2.5 ms are pretty long to my opinion, we are using a recent Pentium 4 machine.

Is there any way to reduce this latency?
NB: I tried to do a niHSDIO_CommitDynamic( RxSession ) earlier on but that gives errors.

[Ryan_M]

emvee,

Do you have the ability to trigger the acquisition from the generation session?  You could route a Data Active event from your generation session as a start trigger to your acquisition session.  In this fashion, your acquisition will not actually receive data until your generation session is generating data.  You would need to start your acquisition session first so that it is looking for the trigger before the generation task sends it.  If you have an open PFI terminal and your DUT has some synchronous event that it can export, that would be the signal to trigger from.  However, if your DUT does not have a synchronous event, you could route the event and receive the trigger on the same PFI channel.  I would recommend using PFI 0 with no cable attached to minimize transmission effects.  This would not account for any latency in your transmission path (ie DUT propagation delay) but would remove significant latencies introduced by software timed operations.

Does this seem suitable?

[emvee]

Ryan,

Thanks for your answer.

The capture buffer taken by the 2.5 ms delay is not a problem. I already used a trigger in a particular situation and it works okay.

The actual worry (unlike the title) is the (processor) time it takes. I find it strange that starting acquisition takes about 17.5 ms and generation 2.5 ms while the complete capturing is done in the hardware of the card and a commit has been done; I would expect this could be done by writing a start bit to a certain register and that should take less then one us. We use the card in repetitive mode where the acquisition results will provide the data for the next acquisition session and these delays severely limit the overall performance.