Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

faster data processing

Hello

I was using the DAQ Assistant in Labview 7.1 to read and output voltages that I have to perform a control loop on.

As this was reading too slow for my application I re-configured the inputs and outputs (see attached) but this still appears to be slow.

I have tried reading the examples given in Labview but they are very complicated and generate errors when I try to run them.

Ideally my program should input and output samples every 5 or 10ms.


Thanks
0 Kudos
Message 1 of 3
(2,546 Views)
Sorry, I don't have any DAQ hardware and drivers on my current computer so I cannot comment on anything DAQ related. Still, your "write LVM file" seems oddly configured.

If this is supposed to be a control loop, I do not understand why you would need to
(1) rename the existing file AND
(2) write to a new file
with every single loop iteration. This cannot really be your intention!

A truly fast control loop does not write to files at all, but simply generates e.g. an analog output response as a function of the inputs. If you really need to record to file, configure it to append to the current file.
0 Kudos
Message 2 of 3
(2,532 Views)
Yaauldgoat,

I took a look at your VI, and have made some modifications. As altenbach mentioned, opening, writing, and closing a file all is very inefficient, and probably not a great idea in a control loop. I have also modified the DAQ code to speed it up. The DAQmx API maintains a lot of state information. When you use the write VI by itself, every time it is run, it must transition the task through all of it's states, write, and transition the task all the back to its idle state. I have added code with will move the task to a running state before the control loop starts. I then write in the loop, but the task is left in a started state. When the loop ends, the I then stop and clear the tasks. This should be considerable amount faster than the prior implementation. However this may be a non-factor because of the file access. The one final thing I noticed is that you have the output of the Write VI wired to a loop tunnel. As the loop executes, I believe LabVIEW is going to be building an array to store data in at that tunnel. The longer you run the VI, the more data will acquire, and the more memory LabVIEW will need to allocate for this. As arrays get big, this can be a time-consuming operation. Especially given the fact that the terminal is unwired, I would probably remove it. I'll attach my modified VI.

I hope this helps,
Dan
0 Kudos
Message 3 of 3
(2,525 Views)