Digital output waveform of NI-PCIe-6259 is taking 3microseconds even when through PCIe frquency is 10MHz

[UzumakiNaruto]

#include <stdio.h>
#include <stdint.h>
#include <NIDAQmx.h>

#define DAQmxErrChk(functionCall) if( DAQmxFailed(error=(functionCall)) ) goto Error; else

int main(void)
{
int error=0;
TaskHandle taskHandle=0;
int32 data=1;
char errBuff[2048]={'\0'};
int32 written;

/*********************************************/
// DAQmx Configure Code
/*********************************************/
DAQmxErrChk (DAQmxCreateTask("",&taskHandle));
DAQmxErrChk (DAQmxCreateDOChan(taskHandle,"Dev1/port0/line24","",DAQmx_Val_ChanForAllLines));

/*********************************************/
// DAQmx Start Code
/*********************************************/
DAQmxErrChk (DAQmxStartTask(taskHandle));

while(1){

/*********************************************/
// DAQmx Write Code
/*********************************************/

DAQmxErrChk (DAQmxWriteDigitalU32(taskHandle,1,1,10,DAQmx_Val_GroupByChannel,&data,&written,NULL));

data=~data;

}
Error:
if( DAQmxFailed(error) )
DAQmxGetExtendedErrorInfo(errBuff,2048);
if( taskHandle!=0 ) {
/*********************************************/
// DAQmx Stop Code
/*********************************************/
DAQmxStopTask(taskHandle);
DAQmxClearTask(taskHandle);
}
if( DAQmxFailed(error) )
printf("DAQmx Error: %s\n",errBuff);
printf("End of program, press Enter key to quit\n");
getchar();
return 0;
}

I'm using Linux Ubuntu 22.04LTS, I'm running the code.

when i toggle the data without any delay and plot the digital waveform in oscilloscope, i find that pulse width is around 3 microseconds as it should be  0.1microseconds according to board spec of 10 MHz

please help me in this case as fast as possible

Regards

Uzumaki

[Kevin_Price]

You're using software timing to generate the pulse, so your pulse width will depend on code execution speed (including the many layers down below the top-level driver API).

You would need to set up a hardware-timed DO task which the 6259 doesn't support directly.  It *does* support it indirectly using a method known as "correlated DIO" whereby the DO task must borrow a sample clock from some external source.  I often used a counter pulse train task to generate such a clock for a correlated DIO task when I was using M-series 62xx devices.

-Kevin P

[UzumakiNaruto]

Thanks for reply Kevin_price

"You're using software timing to generate the pulse, so your pulse width will depend on code execution speed (including the many layers down below the top-level driver API)."

can you explain it more briefly how i am using software timing because its typically impossible to generate aa proper 3microseconds square wave from digital output port. and moreover I'm not using any "delay function" or "timer" or "usleep" to generate this 3 microseconds. it is doing by its own

[Kevin_Price]

Software timing means that you're making a software function call to the driver API to set the state high and then making another software function call to the driver API to set the state low.  And so on.  Each of those function calls takes time to execute -- there are many layers of sub-functions to work through below the top-level API function you call directly.

You need hardware-based timing, which involves "borrowing" a sample clock and writing a buffer of DO values to generate before starting the task.

If you merely want a constant 5 MHz pulse train, you can do that much more easily with a counter output task.  That's one of the things they're *designed* for.

-Kevin P

[UzumakiNaruto]

Thanks for the reply Kevin_Price

"Software timing means that you're making a software function call to the driver API to set the state high and then making another software function call to the driver API to set the state low.  And so on.  Each of those function calls takes time to execute -- there are many layers of sub-functions to work through below the top-level API function you call directly."

is there any way to find out find the driver API (i.e) software function call to know how it is functionating. Like typically in a C program if  I write a 1us delay toggling data from 0 to 1 and 1 to 0, and when i see the output in oscilloscope  i find that the square pulse width varies and it is not constant , but when i increase the delay b/w toggling like assume 1milliseconds i find a perfect square wave.

here my issue is they what timer they have implemented that its giving perfect square wave in microseconds range.

[ZYOng]

is there any way to find out find the driver API (i.e) software function call to know how it is functionating.

See C:\Users\Public\Documents\National Instruments\NI-DAQ\Documentation\NI-DAQmx C Reference Help

Like typically in a C program if  I write a 1us delay toggling data from 0 to 1 and 1 to 0, and when i see the output in oscilloscope  i find that the square pulse width varies and it is not constant , but when i increase the delay b/w toggling like assume 1milliseconds i find a perfect square wave.

It depends on which API you use, but it is usually only accurate to 1 millisecond on Windows.

You should always use hardware timing for accuracy smaller than millisecond. You can refer to Synchronize Correlated Digital Output with Analog Input Using NI-DAQmx and combine these examples

C:\Users\Public\Documents\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Digital\Generate Values\Cont Write Dig Port-Ext Clk

C:\Users\Public\Documents\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Analog In\Measure Voltage\Cont Acq-Int Clk

[Kevin_Price]

---

@UzumakiNaruto wrote:

here my issue is they what timer they have implemented that its giving perfect square wave in microseconds range.

---

Who is "they"?  It sounded like you were describing your own code.

When we talk about "hardware timing", we're talking about using the DAQ device's circuitry, including a built-in 80 MHz timebase clock, to regulate sample timing.  Extremely precise because there's no OS or software involved to cause timing variations.

-Kevin P