With USB devices and digital trigger 1 sample is output before trigger is received.

[sradbil]

I am using NI-DAQmx 8.7.1f3. (I have also tested with 8.8 and a USB-6218).

My program is using  a rising digital edge trigger on PFI0 to trigger the acquisition:

        DAQmxErrChk (DAQmxCfgDigEdgeStartTrig(taskHandle,"PFI0",DAQmx_Val_Rising));

When using a USB-6211, USB-6218 or USB-6255 calling DAQmxGetWriteTotalSampPerChanGenerated() returns 1 sample output even before the trigger signal is sent. The scope doesn't show that a sample was actually output though.

When using a PCI-6251 or PCI-6229   DAQmxGetWriteTotalSampPerChanGenerated() returns the expected 0 samples output before the trigger signal is sent.

 I am attaching the program MultVoltUpdates-IntClk-DigStart.c

This is based very closely on the shipped example of the same name with the addition of the ability to provide the Device ID if you don't want the default of Dev1 as well  as code to sleep for 1 second after DAQmxStartTask() is called and then DAQmxGetWriteTotalSampPerChanGenerated() is called. That is called again after the task is done or has timed out.

When using a PCI-6251 or PCI-6229 and not providing the digital trigger signal the output is:

>VC_MultVoltUpdates_IntClk_DigStart.exe Dev5
Working with Dev5, PCI-6229
Generated 0 samples.
DAQmx Error: Measurements: Wait Until Done did not indicate that the task was done within the specified timeout.

Increase the timeout, check the program, and make sure connections for external timing and triggering are in place.
Task Name: _unnamedTask<0>

Status Code: -200560
End of program, press Enter key to quit

The line "Generated 0 samples" is the expected output and since I don't provide the trigger signal the timeout is also expected.

For the PCI-6251 the results are the same.

But for the USB devices the output is:

>VC_MultVoltUpdates_IntClk_DigStart.exe Dev6
Working with Dev6, USB-6218
Generated 1 samples.
DAQmx Error: Measurements: Wait Until Done did not indicate that the task was done within the specified timeout.

Increase the timeout, check the program, and make sure connections for external timing and triggering are in place.
Task Name: _unnamedTask<0>

Status Code: -200560
End of program, press Enter key to quit

Generated 1 samples is not expected. This is the problem.

The timeout is expected as no trigger signal is provided.

My actual program depends on  DAQmxGetWriteTotalSampPerChanGenerated() to return an accurate number and I believe that for the USB devices it is not working properly.

[PBear]

Hi Sherryl,

Is this difference a problem though? What is the performance that you get after the trigger comes? If the data that is read back into your application after the trigger is valid data then I wouldn't worry too much about this. This may be standard behaviour on USB DAQ devices but unless actual performance is not affected, then this seems to be expected.

[sradbil]

Hi PBear,

Thanks so much for responding.

Yes, the difference is a huge problem.

My app depends on the time that the first sample was generated.

Since this first sample on the USB device is generated spuriously when DAQmxStartTask is called and the actual trigger may come at any time later or not at all, the program will not work correctly for the USB M-series devices. PCI M-series devices do not behave like this.

When you ask about the data read back into my app what do you mean? This is AO and we're outputting data.

If this is standard  behavior on USB DAQ devices does that mean I missed it somewhere in the documentation?

I didn't mention this because I broke the problem down to it's smallest representation, but the AI subsystem does not behave in this way. That is, I configure AI for a digital edge trigger and the device does not begin inputting data until the trigger is actually received. As a matter of fact, that's how the problem was discovered. AI and AO were wired to the same trigger signal and AO reported it started immediately when DAQmxStartTask was called while AI correctly waits for the signal. 

Quite frankly I'd be surprised to learn this is intended behavior.

[PBear]

Hi Sherryl,

I can verify this behavior on a USB 625x device but it should not affect your application. The generated sample is not physically output until the trigger is asserted and this can be verified simply with a loopback or external scope. The generated sample is sitting in the board's onboard FIFO until the trigger comes.

I understand that on paper this may appear to be a huge problem (as it's implied that the sample has been generated physically) but in application you shouldn't have an issue. If this truly does affect your application, we can look into clarifying the behavior further.

[sradbil]

Hi PBear,

And thanks for your explanation.

As I mentioned in my original post I also verified this with these devices: USB-6255, USB-6211 and USB-6218.

PCI devices do not behave this way.

This is more than a huge problem on paper.

If the sample is still in the FIFO waiting for the trigger, then  DAQmxGetWriteTotalSampPerChanGenerated() should return 0, just like the PCI devices do. It should not report that one sample has been generated when in fact zero samples have been generated.

It truly does affect my application by producing erroneous data for these USB devices and I would appreciate if you could look into clarifying the behavior further, as you kindly offered.

Thanks again, 

[PBear]

Hi Sherryl,

I will look into this behavior. I still would like to know how this is a huge problem on an application level rather than just an observed difference in software calls. Does your code specifically have a case for the different values that come back for the total samples generated? If so then I agree that this difference will affect code execution amongst different families (USB vs. PCI). This can also be programatically fixed using case structures and reading device IDs upon running your VI.

But if the issue is simply cosmetic (i.e., when the trigger comes, your pre-buffered waveform is output the same as on a PCI device), then you should be able to still be successful with your triggered output application.

Please realize that I am talking about a difference between how your hardware is performing versus an API call to return a registered value (the samples written).

[sradbil]

Hi PBear,

This is a C application written entirely by calling the NI-DAQmx C API calls.

That is why the original reproduction code was a C program. 

There is no VI and I'm not sure what you mean by fixing it using case structures. 

They are not discussed in the NI-DAQmx  C Reference Help:

"C:\Program Files\National Instruments\NI-DAQ\Docs\cdaqmx.chm" 

The issue is not cosmetic.

We ask the device "how many samples have you generated" and it tells us that it generated 1 sample.

But even as your wrote - it has not generated 1 sample.

Since we are incorrectly told that 1 sample has been generated the application continues as if 1 sample has been generated and behaves incorrectly for the USB-62xx devices because the return erroneous data.

Hope this clarifies why we need  DAQmxGetWriteTotalSampPerChanGenerated() to return the correct number of samples generated.

Thanks, 

[PBear]

Hi Sherryl,

I apologize for using the term "VI" whereas I do realize your application is coded in C. It sounds like the behavior affects your code logic and not particularly the performance of the board. When sent a trigger to begin output, the board responds as programmed.

I do agree that this property should return the same value regardless of family (USB vs. PCI) but this is an issue I will raise to some of our developers. We appreciate the feed back but in the meantime, changing your code logic to reflect this difference should mitigate your issue. Since the hardware is outputting and acquiring as desired, polling the device upon run and determining the family can give you information to programatically adapt to the fact that there is this difference between the two that you have found.

"...the application continues as if 1 sample has been generated and behaves incorrectly for the USB-62xx devices because the return erroneous data."

I would recommend reworking some of your code to alleviate your strict dependency on the DAQmxGetWriteTotalSampPerChanGenerated value for the time being.

[stilly32]

All,

This has been fixed as of DAQmx 8.9. It was filed under CAR 125481. 

Thanks, 

Andrew S