LabVIEW programs are governed by something called the Principle of Data Flow. Any Function or Structure (such as a Case Statement, a Frame Sequence, a While Loop, or a subVI) cannot start until all of its inputs have data, will not exit until all of its Outputs have data (from within the Function or Structure), and until everything inside the Function or Structure has to run.
When you have a DAQ Loop, particularly one (like yours) that acquires data of a fixed amount (1000 samples) at a fixed rate (1 kHz), that imposes a "clock" on the loop because of the Principle of Data Flow -- to acquire 1000 samples at 1 kHz will take precisely 1 second.
Consider, now, a loop that only takes samples, but doesn't do anything with them (just lets them be ignored). How fast will this loop run? If it's taking 1000 samples at 1 kHz, it will run precisely once/second (as it needs to get the 1000 samples before it can repeat, then wait again until it has the samples, repeats and waits again, etc.).
Now put some processing inside the loop. Let's say it takes half a second to run. No problem --the DAQ Read, itself, takes maybe 1 millisecond (probably only a few microseconds), leaving almost the entire second that the loop "waits" for the DAQ Read to finish to do any other processing, so it will run just fine.
But what if some operations take more time? The Principle of Data Flow says the loop won't finish (and be able to repeat) until everything inside has run. In other words, the other processing in the loop slows it down.
How do you fix this? Get all of the processing out of the DAQ loop, and put it into another Parallel Loop. Do a little research for the Producer/Consumer Design Pattern in LabVIEW. This will enable you to "have your DAQ" and "process it, too".
Bob Schor
