DAQmx write to buffer in Labview

[Gabi1]

it seems i have an efficiency issue with "write to buffer" in DAQmx.

up to now i was using traditional DAQ in C++ for this kind of operations, and it worked great:

i create some data points, and send them to buffer on the fly. actually not directly to it, but to its pointer (that is the whole difference!). i could fill and keep track of my position in buffer with very little physical memory shifts.

how i can do it in Labview: well, since i cannot access directly the allocated memory for my buffer (i allocate the max of 16MB - another problem: why not more???), i could only hope Labview will take care of that.

unfortunately not: using property nodes i can know where is my "write" position in the buffer, but trying to "on the fly" deliver my data points to the buffer lead to extremely slow filling of the buffer !! the reason seems to be buffer allocation every time i call it.

the only workaround i have right now is to fill small arrays of at least 100000 elements, and deliver them to the "write to buffer" DAQmx function.

this solution works kind of, but forces me to keep trac all the time about my array filling status. for several reasons this kind of lower my flexibility by order of magnitude.

my question is then: is there a way to get documentation on the DLL underlying the vi? this is not one of the c++ functions.

or: is there any work around this problem? can i "tric" the vi to not reallocate memory for each data point?

[Philipp R.]

Dear Gabi1

Your request lacks some important information: Which hard- and software
(versions) are you using? What's the exact name of that "write to buffer"
function you are talking about? What are you trying to do, after all,
analog acquisition, digital input etc.?

It might help a lot if you just posted (a stripped-down version of) your
VI!

Best regards

Philipp Roessler

[Gabi1]

Philipp,

Thanks for your answer and interest.

You are right i am sorry, lots of info missing. here i correct for that.

the computer i use is a dual core 2GHz, with 2GB of RAM.

i am using LV 8.2, with MAX 4.1, and the DAQmx drivers that came with the LV DVD. i know there are newer drivers, and on some computers i installed them, with very little changes on the behavior and name of properties.

i think the behavior i am reporting is not related to which card do i use, since it is a DAQmx driver problem. anihow, i am using a NI 6533 card, 2MHz 32bit DIO. i am using it at maximum frequency for generating pattern, and it is used for controlling a wide array of instruments selfbuilt.

here is a sample diagram of how i want it to look like:

i hope it is clear enough. the main point being that i should be able to input single point data to the "DAQmx write" faster than i actually write to port, i.e. faster than 2MHz.

Actually, this write to buffer is extremely slow.

a workaround i have is looking like this:

in this case i fill out an array, and feed the "DAQmx write" with arrays rather than single points. several disadvantages: it makes my code very cumbersome, and i have to come around a lot of related problems, making my solution much less versatile. the attached vi is only a test example and doesnt show the complication of my actual code. 

one specific point is that i have the last sent array is generally not full, meaning some values are the default (or worse previously written data...). i could of course clean this, but it make a lot of computation time, very expensive for me if i want to operate at 2MHz.

to resume: i want the "DAQmx write" to be able to write data to memory faster than 2MHz. i think the problem is the underlying driver, but i have no documentation about it. please do not propose me to go to NI6534 or the newer cards . i am considering it, but it will not change this problem, which is very LabViEW related. in C coding, i simply fill my own memory, and point traditional DAQ to it. it works perfectly there.

attached is also the test code. i did not tested it (my configuration requires very specific input data to test).

thanks for any proposition!

Message Edited by Gabi1 on 06-06-2007 02:44 AM

[Gabi1]

Hello Philipp,

i was really hoping to get some input.

i do think the behavior shown is a bug, and should be addressed. or maybe i am doing something basically wrong?

[TobiasL]

Hi Gabi1!

The Problem is that if you want to write one sample after the other other with the while loop it will never reach a time which is fast enought tat your samples for the 2MHz ouput where generated. if calculate the running time of one interation of the while loop it will take some ms, because in the DAQmx write VI there is called a DAQmx dll. the only was you can do that is to generate a big numer of samples you want to send out befor you do tat and wire the array to the DAQmx VI.

In the DAQmx write VI there is given a Pointer to your Data Array and the dll gets the data from the memory where you created the data in LV.

I think its depending to the card that you only can use the 16MB Buffer Memory.

Best Regards
Tobias Lange

[Gabi1]

Hi Tobias!

i think we had a mail communication on a related subject

first i discovered the 16MB limit is one defined actually by the operating system. Windows seems not to allow allocation of more than 16MB. (xp). not sure why.

second, running the "write to buffer" as single channel single point, it is real, REAL slow. below the KHz slow! and it is very specific to LV (and not related to computation other than insert into this function).

Again, in a previous apps in C++ i had it running in a fast loop, using traditional daq with single point. worked perfect there.

i do think there is something in the DLL that is weird. is it the same as the library call for C?

i will try with Traditional DAQ ,see how fast is it there with LV.

Anyhow, would be great if you could ask the LV designers about it, just to be sure, together with this timing import clock issue.

Thanks!

[TobiasL]

Hi Gabi1!

Yes we had mailcontact about the issue!

The thing the while loop is so slow is related to big overhead which is caused by LV, the SubVI call and the DLL call inside the subVI.

For the timing issue, i thing i had already informed you, i sent it to the developers an hope quckly to get an answer.

Regards Tobias