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

[UzumakiNaruto]

Thanks for the reply Kevin_Price

I'm doing DAQmx C example program in Linux Ubuntu 22.04 LTS, If you see those example you can find that they have function calls to use the built-in clock "DAQmxCfgSampClkTiming(MyTask, "" , MySampFrequency, DAQmx_Val_Rising, DAQmx_Val_ContSamps, NumberOfSamp);"

If i use this function then i can access the built in clock, but example of 

"C:\Users\Public\Documents\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Digital\Generate Values\Cont Write Dig Port"  does not use this function and gives me data toggling at 3us. This is why i was asking at 10Mhz spec typically  it should provide 0.1us data toggling.

"Again, the 10MHz spec for the device is a spec that *only* applies to hardware-timed generation.  NI never gives "specs" on software timing because it's system-dependent, not entirely predictable, and largely outside their control."

i understand, but the example code NI using is their function calls to produce the waveform at 3us. When you said NI is using "hardware timing" I got confused. is there any solution to find why 3us using NI DAQmx function calls but not using a general C code to produce even 50us togging waveform

[Kevin_Price]

I'm confused too.  Surprising to me, I found that I *did* have C examples installed by NI-DAQ -- I just never used or looked for them before.   However, I did not find the example you referenced in the path you showed. 

The only "Cont Write" example *also* uses an external clock and includes the config line:

"DAQmxErrChk (DAQmxCfgSampClkTiming(taskHandle,"/Dev1/PFI0",1000.0,DAQmx_Val_Rising,DAQmx_Val_ContSamps,1000));"

But beyond that, I'm not really entirely sure what the continued question even is any more.  The question I *thought* you had has been pretty thoroughly answered by now.  Toggling DO via software calls will be slower and have less reliable timing than a DO task that uses a hardware sample clock.   And if you just want to toggle at fixed rate, it'll be much simpler to generate such a pulse train with a counter task.

Maybe someone who programs C could help if you'd attach both versions of code -- both your own and the example you reference that seems to work better.  Write up some clear description of what you expect from each, what you actually observe from each, and your method for making that observation.

-Kevin P

[UzumakiNaruto]

Thanks for the reply Kevin_Price

sorry for the delayed reply 

if you check  "write dig port" example im just generating pulse train by toggling data below im attaching the code

#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;
}

here if you see im just toggling the data to get square wave and im not using any clock here. you said that software calls is taking that 3us for toggling and i agree 

when we typically write a C code take for example led blinking , the led blinks on and off with respect to some delay. similarly im just toggling data with 1 us delay and imnot acquiring a perfect square pulse train when seen in oscilloscope , how this above code is able to do that is my query here.

if anyone worked on this DAQmx code will be able to answer. please do reply

[Kevin_Price]

Sorry, I still can't quite decipher what your situation and question are.  In the original post, you observed 3 usec pulse width when expecting 0.1 usec.  I thought that was answered in msgs #2 & 4.

Then in msg #5 you say that you "write a 1us delay toggling data from 0 to 1 and 1 to 0".  I'm unaware of any timing function that would allow you to define a 1 usec delay and haven't seen any reference to any such function in the code you've posted.

Then in msg #9 you emphasize the seeming precision of a 3 usec pulse width but also the seeming imprecision and variability of any pulse width less than 50 usec.   I really don't understand what two things you're contrasting there.

Then in msg #11 you asked "is there any solution to find why 3us using NI DAQmx function calls but not using a general C code to produce even 50us togging waveform"?   Again, I really don't understand the distinction you seem to be making between a C code example from NI with NI DAQmx function calls and what you call "general C code".

Finally now in msg #13 you're remarking that attempts to do a 1 usec delay (again, how?  what delay function?) produce an imperfect pulse train on a scope.  Yes, that's completely expected.  Controlling your timing with software will result in imperfect timing.  *AND* a slower top speed than device-level hardware timing which could work reliably and consistently at 0.1 usec pulse width.

And I'll emphasize again that if you want a perfect square wave pulse train, you'd be MUCH better off generating it with a counter task which can give you even *better* timing resolution.

-Kevin P

[UzumakiNaruto]

Thank you for the reply

Sorry for the delayed reply Kevin_Price

I know its quite confusing, in msg13 the code is NI example code. and typically hardware spec says 10Mhz and i understand that its using counter not software timing which gives 3us instead of 0.1us waveform.

"General C code" means my own code not using NI example code eg:-

int data =1;

while(1){

data ~= data;

usleep(1);

}

like this without using DAQ function when i generate a square pulse its not giving accurately 1 us pulse.

[Kevin_Price]

I'm trying, but still not clearly following.

---

@UzumakiNaruto wrote:

I know its quite confusing, in msg13 the code is NI example code. and typically hardware spec says 10Mhz and i understand that its using counter not software timing which gives 3us instead of 0.1us waveform

It was hard to find a way to interpret that sentence in a way that made sense to me.  I *think* I finally got it after several tries.  At first it sounded like you were saying that the msg13 code used a counter which resulted in 3us timing and were then contrasting that against software timing that would give a 0.1us waveform.

    Eventually I *think* I figured out that you were saying that the *spec* is based on using a counter clock for hardware timing and that's why 10 MHz can be achieved.  However when software timing is used, pulse widths are 3 us rather than 0.1us.

---

"General C code" means my own code not using NI example code eg:-

int data =1;

while(1){

data ~= data;

usleep(1);

}

like this without using DAQ function when i generate a square pulse its not giving accurately 1 us pulse.

I don't know text language functions but I'm taking a guess that usleep() is intended to provide a processing delay in units of microseconds.  You say you don't get 1 usec pulses accurately and I'm at least a little confused again.

   Two reasons.  First, this is pretty clearly a case of depending on software timing again and I thought you had gotten clear on the idea that software timing will always be prone to such timing variations.   So the failure to achieve accurate, reliable, precise 1 usec pulses shouldn't be surprising any more.   Second, I can't see how you'd be *evaluating* the timing you get from toggling a variable in software.  How is the "time of toggle" established and captured?  How do you know what timing you're getting?

-Kevin P