PXI-6229 DO Data transfer mechanism

[marius.karosevicius]

Hi, I am trying to generate 100kHz quadrature encoder signal on 2 DO lines on PXI-6229. The DO uses counter0 and PFI0 as an external clock source.

The encoder signal should consist of 10000 periods therefore I use 400kHz sampling rate and send 40000 samples (4 samples each period).

The DAQ throws an error: 

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 use a product with more onboard memory or reduce the number of programs your computer is executing concurrently.

I found that using Interrupts instead of DMA as the data transfer mechanism allows me to generate such signal. However I am not sure if this is the correct solution as it depends on CPU load.

I read that DMA is the fastest method to transfer data. Then why can't it keep up with the 400kHz clock? 

Thank you.

[Kevin_Price]

That's surprising -- all else being equal, DMA *should* support higher bandwidth than interrupts.  Can you post your code, saved back several versions to, say, LV 2018?

Also, a repetitive signal shouldn't need to be rewritten over and over again -- DAQmx supports output "regeneration" by default, where the driver treats the array of data as a circular buffer and keeps wrapping around to deliver it down to the device over and over again.

When the output pattern is relatively short and unchanging throughout the task, it's also an option to configure the task to use onboard memory only.  Then DAQmx will deliver the data down to the device just once, and the device itself will thereafter generate the signals by treating its own local memory as a circular buffer.

I suspect your simulated quadrature output is just such a repetitive signal, which would let you make use of the regeneration feature.

-Kevin P

[marius.karosevicius]

Thank you, Kevin,

My code is implemented in TestStand, calling DAQmx VIs, but for simplicity I've put everything in LabVIEW 2016 VI (attached).

I does the same as my sequence and returns the error when used with DMA transfer. 

You are right about regeneration - it doesn't work at all if I disable it. Using onboard memory only (FIFO regeneration) is not an option as all the data must fit on the FIFO, which size is 2047.

[ZYOng]

Two odd things I observe from your code:

1. The analog task is created and started after the counter output task (which generates the sample clock) is started. We usually start the task before the sample clock is generated.

2. You mentioned that you disable the Regeneration but are calling the DAQmx Write VI once with only 4 samples. However, you configure the task to output 40k sample points.

[marius.karosevicius]

Thanks, ZYOng.

1. Changing the order of tasks doesn't make any difference (and shouldn't, as the counter pulse generation is continuous).

2. Normally, I do not disable regeneration, I even tried enabling it (even though it is enabled by default) before running the task.

However your comment gave me an idea to fill up the data array with 40k samples prior to writing (attached new VI).

This way it works with DMA, with regeneration enabled and disabled. And I think this could be the solution for finite samples generation. However the regeneration is needed when generating continuously (not for this particular application, but may be needed in the future).

Therefore the question why DMA can't keep up persists.

I should add that PXI-6229 is used with PXI-1078 chassis (PXIe Hybrid slot), and with PXIe-8360 remote control module.

[ZYOng]

1. Changing the order of tasks doesn't make any difference (and shouldn't, as the counter pulse generation is continuous).

It does not matter in your case because you have only one task running. Usually, we use an external clock to synchronize multiple tasks. In that case, you want to start and arm all the tasks before generating the clock. I am giving a recommendation based on the best practice.

I should add that PXI-6229 is used with PXI-1078 chassis (PXIe Hybrid slot), and with PXIe-8360 remote control module.

The usage of a remote controller does introduce extra latency, as PCI packets need to go through multiple PCI switches. I am not sure if it will help, but try to use the U8 or U16 instance of DAQmx Write. Maybe a smaller data packet will help to mitigate the communication issues.

[marius.karosevicius]

We use an external clock to synchronize multiple tasks

That's a great idea! 

Try to use the U8 or U16 instance of DAQmx

This is not an option, because PXI-6229 DIO Port 0 has 32 lines and doesn't accept anything less than U32.