LabVIEW
Micro-Nuggets !!! ~~~~ Post 'em if you got 'em
@broken Arrow wrote:
Did you know...
Wiring 0 to the Timeout of a DAQmx Read results in LabVIEW's attempt to read data ONCE? This can be a useful troubleshooting or benchmarking tool to ensure (for example) your producer is synched up to your comsumer.
Another approach to "find out how many samples have been collected" there is a DAQmx property node that will return the number of samples that have been acquired and are waiting in the buffer. I almost always use that node to control how many samples I want to retieve. By only asking for what has already been acquired, the operation will NOT stall waiting for data but will return the acquired data as fast as the CPU can click.
Ben
Ben wrote:Another approach to "find out how many samples have been collected" there is a DAQmx property node that will return the number of samples that have been acquired and are waiting in the buffer. I almost always use that node to control how many samples I want to retieve. By only asking for what has already been acquired, the operation will NOT stall waiting for data but will return the acquired data as fast as the CPU can click.
Ben
Yes! Those nodes are very useful.
If you setup your acquisition of samples predicated on a loop timer, you can monitor a DAQmx property node to see if you are indeed getting what you think. On Windows, it ain't going to be perfect. I say this because I've seen where a programmer might expect 500 samples based on a 500mS loop acquiring data at 1000S/sec, so you might do math on the samples expecting 500. Don't do it. I troubleshot (is that a word?) a system by reading property nodes and found this program was reading 499, 500, or 501 samples per loop. There was math done downstream with a constant of 500.
Another neato DAQmx trick to avoid waiting is to use DAQmx properties to control how you access the read buffer. I've done a lot of apps that didn't need a contiguous, lossless stream of data, but *did* want to be able to show "what just happened" at any given moment. Here's a snippet I made someone recently to illustrate. (Note that you could choose to set or change the "RelativeTo" and "Offset" values while the task is running.)
-Kevin P
@Ben wrote:
WHen writting to a proprietary file format I was faced with slow file writes such that it took a long time to write ten seconds worth of data (about 21 Mbytes). I was writting one byte at a time.
Adding a type cast to U64 made a big difference.
The same data gets written but in larger chunks.
Ben
Why not just write the array in its entirity and set the "prepend array or string size" false?
I used the property node retain control whilst waiting for a long data acquisition, could be several minuets, this allowed me to place a thermometer style progress indicator on the pannel & use a notifier to stop acquisition
What happens if you just write the cluster as binary? I did that just today with a programs settings, seemed quite fast.
/Y
Problem - you want a grid with a dropdown box in one of the columns. You create a typedef cluster with a combobox for the dropdown. The items in the dropdown are identical for each array element.
Solution - change the items on the fly. This uses Array Row Point To Row.vi by JDave on Lava.
The "Children Column" below effectively has unique selections for each row.
