I appreciate the efforts you're putting into these diagrams to try to help clarify the questions. But I'm still not understanding the intended timing relationship between the "Known External Signal" clock and the (apparently) variable frequency pulse train output.
Previous sketched timing diagrams showed apparently constant rate pulses only while the KES was high. That led to my suggestion #2 back in msg #13. Your scope pics show variable freq pulses whose timing has no discernible relationship to the KES.
What do you want it to look like and what purpose does that serve in your application? Why is it important to change over to sample-clock based buffered pulse output instead of using implicit timing? If that change is feasible, what signal will act as the sample clock?
Now I'll address your questions in red from Question_Reply_4_2.jpg
1. When you specify an external signal as a sample clock for your AO task, the 'Rate' input mostly doesn't matter, as you found. I talked about what role it *does* play in the middle section of my msg #15. But it's the specified external signal itself that drives sampling, whatever that signal's rate is, and regardless of how well you've estimated it with your software 'Rate' input to DAQmx Timing.
2. I'm not able to interpret key parts of your CO code but here's what I *think* I see going on. First some background that's key: pulses are defined to be in idle state first and then in active state. With the default idle state being low that means that pulses are defined by a low time followed by a high time.
Another thing to know is that when you update the pulse timing parameters for an active pulse task, they will *not* interrupt and modify a pulse that's in progress. The new timing parameters won't take effect until the present pulse is completed. If you follow your scope traces carefully, you'll see that after each sample clock rising edge, the pulse timing changes the *next* time the pulse finishes its high state.
That's why pulses don't line up with the KES. The KES is used to decide when to put new pulse timing parameters "next in line" for the task to use at its next opportunity. But the timing for that opportunity is dictated by the pulse timing parameters themselves, not the KES.
3. Once again, the 'Rate' terminal input to DAQmx Timing for your CO task is probably entirely meaningless. When you define an external signal as the sample clock, that signal gets used directly regardless of its actual rate. Neither of the 2 roles I described for the 'Rate' terminal back in msg #15 would apply to a *finite* counter output task. (In a finite task, the buffer size is determined more explicitly and does not depend on the 'Rate' terminal input.)
So your scope pics show that you *are* doing sample clocked pulse generation. And your variable freq pulses just aren't lining up nicely with your KES. Which is entirely expected as I mentioned at the end of my msg #15.
It keeps seeming like you're trying to use an unnatural combination of pause triggering, variable freq output, and sample-clock-based freq changes. Are you really sure it's necessary and if so, how and why?
-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.
.PNG){kind=link}
.PNG){kind=link}
.jpg){kind=link}
.jpg){kind=link}
