The bad news is that there are quite a few problems or likely problems in the code you posted.
The (relatively) good news is that many of them are kinda small and/or subtle. I don't have time to walk through a complete rebuild but here's a start:
1. You've got 3 independent sample clocks going for your 3 tasks -- one from an internal constant-rate clock, two from your variable-rate encoders. Though this isn't *always* the wrong thing to do, it doesn't seem like what you want. See #2.
2. When you read from your tasks, you aren't specifying the # samples to read, so the default is to read "whatever amount is presently available in the task buffer". You are very likely to get different #'s of samples from each of the tasks due to the differing sample rates. Thus when you combine all the arrays into a single 2D array, the smaller ones will get padded with 0 values to bring them to the same length as the longest one.
Since you accumulate this data separately up at the Main.vi level, you should combine the 3 tasks' data by bundling into a cluster. A cluster of arrays allows each array to have a different length and no padding will be done. (Better yet, make a typedef of the cluster to give the various data fields names and then use "Bundle By Name").
3. By reading "all available samples" each iteration, DAQmx will return almost instantly, causing you to iterate at a very high rate.
Probably the only thing slowing it down is the attempt to redraw the waveform graph every iteration with your constantly-growing shift register arrays.
Add a wait timer to your main loop. Make it at *least* 100 msec, but I'd probably start with 500 msec. Your brain can't interpret and react to the graph display much quicker than that anyway.
You could also stand to change the graph into a set of charts, one for each task since they have different sample rates and deliver different size chunks of data.
4. Having data arrays of different sizes will affect your file writing too. You shouldn't combine all the data into a single "Write Delimited Spreadsheet" call. That would just bring back the problem with zero-padding the smaller arrays.
If what you *really* want is to share a common sample clock and rate among all 3 tasks, producing equal-length arrays, there's a different set of changes that are probably simpler overall. I'll look for a chance to post again with some hints for that different approach.
-Kevin P
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
