Wanting to help, but a little frustrated at the moment b/c all your posted code has shown a no-triggering configuration. Your recent messages make it sound like you actually *use* triggering when running the experiments *and* that the trigger signal is repeating at 10 kHZ!!!
This is very relevant information that I wish was made much clearer much earlier. (Part of the fault is mine -- I've also been dealing with other threads where the poster kept using the word "trigger" where the word "sample clock" belonged. This is kinda common on the forums, so I've come to sorta gloss over people's verbal mentions of triggers and take my cues from the code. Peoples' verbal descriptions often turn out to be inaccurate.)
Anyway, can you please give a more thorough description of *all* the relevant timing signals involved? That includes all triggers and sample clocks for all tasks involved in this app. Which ones do you control and which are you reacting to? Which repeat and which are one-time only? Of the ones you have to react to, can they assert themselves while you're in the midst of configuring and starting your tasks? In other words, do you have to consider them to be potentially present at any moment? Or do you have some limited control or knowledge over when they could possibly assert?
My reply in msg #8 has a link to a method that would allow for hardware-based retriggering. The best solution is going to be all hardware based if you can get there from here. Anything involving software timing or lots of task starts and stops will inevitably be sub-optimal. And so all these odd & intriguing details are not really the place to focus until *eliminating the possibility* that there's a hardware-based solution.
Again, the approach you've been taking has all the appearance of a sub-optimal solution. Let's stop trying to polish and shine it until we're sure you have to be stuck with it.
What's the big picture here? Why are you wanting to cycle 150 times through a Start-Read-Stop sequence? Is there some condition that should initiate each individual cycle? Or would you simply like to break up a continuous stream of data into 150 distinct packets?
Further, you're looping through that whole 150 iteration loop repeatedly as well. What condition should initiate each of these outer loop cycles? Again, could the task simply run continuously in hardware if you used software to organize the data into the right size chunks?
I'm just no sure we've been focused on the right problem to solve. Instead of ironing out the kinks in a sub-optimal approach, let's change the whole approach (if possible) to something better.
-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.
