how not to realocate memory in a "buffer write" loop

[Gabi1]

Hello,

i posted this also in the DIO board, but maybe this is specifically a Labview problem:

my application requires sending data to all 4 ports of a DIO 32HS at a 2MHz rate, for an undefined length of time.

preparing a bit less than the maximum buffer size (about 64MB /4 it seems) and setting the Buffer control to "reserve", i then begin to send information in arrays of 4 words to the "buffer Write", while cycling trough the buffer. after some initial buffer loading time ( about a second worth of timed output), i begin the output operation with DIO start.

my data being prepared online, i cant use a double buffer configuration (half buffer size being recreated and reloaded), because my application typically stops creating output words in the middle of such half buffer size, leaving the rest of the array full of null values, affecting my output applications.

However "Buffer write" reallocate memory each time a 4-bytes array is sent to it. therefore sending out 10ms worth of data takes 500ms, sending 100ms takes 5seconds!! this makes it impossible to actually prepare online the data to be sent out. by preparing the full length array in advance, the windows limitation of ~16Mwords then limits my output application to max ~8 seconds only.

Is there any way to avoid memory reallocation on calling the Buffer Write? what are actually the elements the dll requires?

i am using traditional NI-DAQ and Labview 7.1 or 8.2.

Thanks for any help on the subject.

[Kevin_Price]

---

However "Buffer write" reallocate memory each time a 4-bytes array is sent to it. therefore sending out 10ms worth of data takes 500ms, sending 100ms takes 5seconds!!

---

I'd be very surprised if this isn't primarily driven by the application code in some way.  Can you post your code?

It may well be that the attempt to call DAQmx Write at a rate of 2 MHz is the main problem.  There is some overhead with every such call and I wouldn't expect you to be able to call that function 2 million times a second.

I also suspect that different application coding would allow you to write much bigger chunks of data at a time rather than only 4-bytes each.  You're right that such a technique makes it harder to "stop gracefully" with desired output values, but I still think that's your best bet overall.

-Kevin P.

[Gabi1]

Hello Kevin,

Thanks for your answer.

attached is some test code (not very clean but should be understandable):

two elements are sent with a time lag of 100ms, during which frame 2 creates a null array of 4 words for about 200000 times (filling the time lag)

the four words are : 16 bits value, channel value 8Bit, and a 2 bit strobe (10 or 11) on port 4.

in this test, i let fill the buffer for this time, check how much time it took, and only after that allow execution out.

the idea of the final code will be to send an undefined nb of elements at various time intervals, to fill the buffer online (regeneratively hopefully) as the execution is taking place. it would be possible if "buffer write" would be fast enough, and i would avoid creating big chuncks of memory , as well as saving on the overall run time (calculation + output execution would be almost parallel, with a short time lag).

if it works, i would just need to introduce some wait commands if buffer filling is faster than execution.

i think the main problem right now is that when i call "buffer write" it realocates memory for its array.

Tell me what you think.