Right choice of sample clock source for maximum output frequency

[ecafer]

Hello everyone,

in my application I want to output a digital signal over four lines with a maximum frequency that my hardware allows. My data consists of 4 digital waveforms, I use OnboardClock as the source of the sample clock. With the setup in the attachment everything works fine till 167 kHz. When I adjust higher output frequencies via the 'MUX period' control on my front panel I get this error:

Error -200621 occurred at DAQmx Stop Task.vi:3590002

Possible reason(s):

Onboard device memory underflow. Because of system and/or bus-bandwidth limitations, the driver could not write data to the device fast enough to keep up with the device output rate.

Reduce your sample rate. If your data transfer method is interrupts, try using DMA or USB Bulk. You can also reduce the number of programs your computer is executing concurrently.

Task Name: MUX

The hardware that I am using is NI PXIe-1073 with NI PXIe-6358. According to the data sheets I should be able to output signals up to a frequency of 10MHz. My Labview version is: 17.0.1f3 (64-Bit)

I tried to use 10MHzRefClock for sample clock and got the same error above.

When I reduced the sample rate a new error occured:

Error -201002 occurred at GUI_Emirali_final_DFA_WE_clean.vi

Possible reason(s):

Sample Clock Rate must match the frequency of the internal timebase specified as the Sample Clock Source.

To use the specified Sample Clock Rate, set the Sample Clock Source to OnboardClock. To use the specified timebase as the Sample Clock, set the Sample Clock Rate to the frequency of that timebase.

Sample Rate: 5.0e6
Source Terminal: /PXI1Slot2/10MHzRefClock

Task Name: MUX

Is it possible to output digital signals with my hardware in Megahertz frequency area? If yes, how should I change my code to achieve this goal?

Any help is welcome.

Best regards,

Ecafer

[Kevin_Price]

- It's much more helpful to post actual code with typical input values "saved as default."

- Stick with "OnboardClock" as your sample clock source.  This is also the default if you leave the input unwired.

- Your error says that the driver isn't able to do its job for you behind the scenes.  I'm quite surprised you see this problem at ~200 kHz sampling rate on a PXI system.

- My only speculation is that perhaps your *task* buffer is very small, putting an unnecessary demand on the driver to keep delivering tiny little chunks of data very frequently.   A not-very-obvious fact is that the task buffer size is established when you first write to the buffer.

   If you have a very short pattern to continuously repeat, one "trick" is to append together maybe 10-100 copies of the pattern and then write this longer pattern in the first call to DAQmx Write.  Either way results in the same repeating pattern being generated, but this way you allow the driver to deliver larger chunks of data less frequently, which is the more efficient way for the driver to transfer data from task to device.

-Kevin P

[ecafer]

Hello Kevin P,

I followed your 'trick' suggestion and increased for every line the number of samples to 100. Unfortunately it didn't help. I am getting following error:

Error -200332 occurred at GUI_Emirali_final_DFA_WE_clean.vi

Possible reason(s):

Specified sample rate is higher than the fastest rate supported by the device.

Property: SampClk.Rate
Corresponding Value: 100.0e6
Maximum Value: 10.0e6

Task Name: MUX

In the attachment you can find the VI. The relevant part is the MUX_ON case in the State Machine Case Structure.

Best regards,

Ecafer

[Kevin_Price]

Well, that's a new error that you seem to have introduced somewhere, seemingly with the GUI input value for 'MUX period [s]'.  This new error prevents the task from ever getting started in the first place, which wouldn't have let you get far enough to see the original error.

The error message pretty much tells you what to do.  You need to specify a sample rate that the device can support.  Did you try that yet?  Try 1 MHz for example.

Also, what I see in your code is a mere 16-sample buffer.  I'd recommend you try making that MUCH larger, especially if you intend to generate at anywhere near the max of 10 MHz.  I'd start the experiment by making a buffer big enough to hold about about 0.01 second worth of data.  That should easily be big enough to prevent the original error you were getting related to data transfer.

   Once you get things running without error, then you can start reducing the size of that buffer to see where the breaking point might be.  But I'd recommend you start with something the system should easily handle such as a 1 MHz sampling and a 10000 sample buffer.

-Kevin P