04-22-2012 12:44 PM
sorry sir .i forgot to attach the coresponding vi.here i am attaching the vi.
04-22-2012 01:26 PM
Tim's suggested solution is generating the random number and if it is greater that .5, the number adds on to the queue. This should generate and add 100 points to the array. So I dont see why this solution will give you 0's and negative numbers.
Are you using FPGA to acquire data or the DAQ system. Is this the raw voltage less or equal to zero you dont want to acquire or the scaled values? Do you want to perform this comparison in FPGA (if using FPGA) or RT or windows? Windows will not give you this sampling rate. You might want to use FPGA + RT architecture for determinism and reliability.
Anyways I see the solution is to use simple less or equal to zero function to collect your data.
04-24-2012 10:41 AM
After looking at your VI, I see your problem - depending on your data, you want to append to one array (but not the other). You have no choice but to append to both arrays during each loop iteration because you're using auto-indexing; that's the nature of the beast. I highly recommend using shift registers instead, so that you can append to either loop during each loop iteration without having to commit anything to the other. There is no solution for "conditionally" adding something to an array using shift registers. See attachment for image of solution - you can apply the same thing to the alternate case, just reversed for the other array; yes, that's a "build array" node I'm using along with an "insert into array" VI.
-Danny
04-24-2012 11:03 AM - edited 04-24-2012 11:05 AM
Will this work?
04-24-2012 11:32 AM
I would use a case structure. You don't want to build an array just to throw it away fractions of a nanosecond later if the value is zero.
04-24-2012 01:04 PM
To get the speed you need to use Replace Arry Subset as stated earlier. Keep track of how many valid data points you have and finaly reduce the array after the loop has finished.
Ian
04-24-2012 01:14 PM
I should have looked in more detail at the earlier posts, my solution is the same as Tim's example.
My code does check the processing time though, on my PC the code processes 500 000 results in about 15 mS so it should be OK working at the quoted data acquisition rate.
Ian
04-24-2012 01:37 PM
Hi altenbach. What I wouldn't give for a mixed assembler listing associated with a LabView diagram. Do you know a functional equivalent? I dearly wonder what the implementation data structures behind the diagram are. Does splitting a wire mean an entire physical copy? How does one learn these things?
All the best
04-24-2012 01:56 PM - edited 04-24-2012 01:57 PM
@acfkt wrote:
Hi altenbach. What I wouldn't give for a mixed assembler listing associated with a LabView diagram. Do you know a functional equivalent? I dearly wonder what the implementation data structures behind the diagram are. Does splitting a wire mean an entire physical copy? How does one learn these things?
Building an array in a loop requires a new memory allocation, however LabVIEW will do preemtive allocation in chunks to keep the cost and overhead down. For fast loops and large final arrays, resizing of arrays is not recommended (build array, delete from array, insert int array, etc). You get significantly better performance if you know the final array size, initialize it once, and then use "replace array subset" to place the data, keeping track of the insert point in another shift register. Trim to the final size at the end.
There are several long discussion here in the forum, but to really learn these things I recommend just playing with it. Code a few altenatives and test then in a robust benchmark framework to see how things perform. The difference can be several orders of magnitude.