At least at a glance, the code generally looks like it ought to work. Two thoughts:
1. Instead of getting into PFI3 vs PFI8 routing stuff, can't you just specify "Dev1/Ctr0InternalOutput" as the AI Sample Clock source? (You may need to right-click the terminal to get at the menu that exposes the so-called "advanced terminals").
2. Try writing both the freq AND duty cycle properties when you want to update the freq. Or try using the DAQmx Write vi instead of a property node. My past experience suggests that writing only the freq property *should* still work, but writing both isn't hard to try and may turn out to help if the behavior of your version of DAQmx differs somehow.
-Kevin P.
P.S. Bonus 3rd thought. I just went back to reread the thread more carefully, including your first screenshot. I'm now thinking that maybe the hardware actually WAS behaving properly, and that you just weren't aware of it. When you query the AI task for it's sampling rate, all the task can know is whatever rate you told it when you configured it outside the loop. So even as you change the counter freq to change the actual hardware sampling rate on the fly, the AI task will continue to report its orig freq. After all, how is *it* supposed to know?
Try an experiment: Set your original freq very low so that the AI task produces a timeout error without getting all the requested samples within the 10 sec timeout window. Run and verify the timeout. Then run again, but after 3-5 seconds set a new frequency that will produce all those samples in another 1 sec or less. Verify that you get the samples rather than timing out. That should demonstrate taht the counter freq change really *does* produce a change to the hardware sample rate, even though the task property node remains unaware.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
