6534 buffer causes continuous digital output delay

[alex@bug.rose.brandeis.edu]

Hi,

I now have NIDAQ 6.9.2f8, and my 6534s are working well. My only problem is
that the full 32M of scarab buffer causes a long delay between the software
and the hardware digital output (Double buffered continuous).

Is there a Set_DAQ_Device_Info command to restrict the board to use only
some of the memory on the modules?(Like the boot.ini max_mem switch in NT),
this would allow some control over the maximum latency. I couldnt find
anything relavent, except ND_FIFO_Transfer_COUNT and ND_None, (which didnt
appear to work).

Alex Stewart

[bman]

Alex

I would suggest using double buffering. This way, you can make your buffer size smaller which will decrease the delay time. Then once the board starts outputting the data, you can transfer new data to the board. There are examples of how to do this in both LabVIEW and with NI-DAQ function calls.

Let me know if you have any questions about this.

Brian

[alex@bug.rose.brandeis.edu]

Thanks Brian,

Yes I am using double buffering, the 6534 board memory is acting like a large fifo, this makes the output reliable, but since the buffer size is 32MB pre channel it takes several seconds for data poured into the fifo to come out at the other end. (Once the fifo fills up). What I want is a smaller apparent delay. I am using the DIG_DB_HalfReady function to poll for when to send the next buffer. If there were a function which would let me see how full the 6534 board memory is then I could control the effective delay.

Is there such a function?

DIG_Block_Check seems not to solve this problem

Alex

[bman]

Alex

Depending on how fast you are outputting the data, you may be ok with turning of the preload feature. You may turn off preloading if the delay is of concern. To disable preloading in LabVIEW, use the DIO Parameter VI and set the Scarabs Preload Enable attribute to OFF. In NIDAQ C, use the Set_DAQ_Device_Info function and set the ND_FIFO_TRANSFER_COUNT to ND_NONE.

Brian

[alex@bug.rose.brandeis.edu]

Thanks again Brian,

I am running at 10Mhz x 32 bits continuously (for months at a time) in a service. So I dont really want to turn preload off completely. I would like to use a smaller size of Buffer, about a megabyte or so would be good.

In any case I already tried using the Set_DAQ_Device_Info function with ND_FIFO_TRANSFER_COUNT set to ND_NONE, and it didnt work for me, I dont know why, but it had essentially no effect.

Alex

[alex@bug.rose.brandeis.edu]

The problem with double bufferring is that the half-buffer-ready is raised when the data is transfered to the board. The double buffered output latency is then dependent on the memory on the board and not on the size of the buffer.

Alex

[alex@bug.rose.brandeis.edu]

I am still trying to find a way to use a 'medium' sized buffer. I feel like Goldilocks, no scarab buffer is too small, 32MBytes is too big, a megabyte or so would be 'just right'.

Alex

[Oleksiy]

Alex,
Did you figure out how to reduce the delay caused by 32Mb output buffering? We are experiencing exactly same problem: the delay is around 6 seconds when operating at 5 Mhz, which corresponds to 32Mb. Thanks,