Your answer to #5 makes it clear that you must NOT stop the task when you want to drop down to a slow sampling rate. I've got 2 basic approaches to suggest:
1. HW-based approach: You're using one counter for your encoder measurement. Is your other counter available to generate your sampling clock? If so, you can simply change that counter output frequency on the fly to change your sampling rate as needed. A possible downside is that the actual data acq buffer won't provide any clues as to which rate was used for which samples. Whether or not this is an issue depends on your app.
There's actually a more complicated possible method based on using a dummy AO task (if you don't have a real hw-timed AO task) as a sample clock because AO rates can also be updated on the fly. Then you could use your 2nd counter to measure the clock so you'd have a record of all the timestamps. You'd need to be careful to keep your starts and reads in sync, but it's surely doable.
2. SW-based approach. Always sample at the same rate and always pull data from the buffer fast enough to keep up. But during the "slow sample modes" times, extract only the portion you care to keep. Overall, this approach is probably simplest, but the former one is too nifty not to mention.
You were already on basically the right track with your thought to share the AI sample clock. What you might not have realized is that you CAN stop the AI Task (making the sample clock cease) WITHOUT stopping the CTR task. Then you could restart the AI at a different rate. During the time the AI task is stopped, there are no sample clock pulses to cause CTR encoder values to be buffered. However, the actual count register will still be incrementing/decrementing appropriately to track position. When you restart AI at a slow rate, you'll just get back to sampling/buffering those position values.
-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.
