I think it's partly just an accident of history. When the DAQmx API was developed, NI didn't yet have hardware that could generate a buffered pulse train. By far the most common use cases for pulse generation were ones where the pulse specs wouldn't change while the task was running. (On-the-fly changes were and are supported for continuous pulse trains, but that's a less common usage.)
They *could* have opted from the beginning to require tasks to call DAQmx Write with scalar values for the pulse specs and look more analogous to AO and DO, but they chose to incorporate it right into DAQmx Create Channel. Overall, I guess I think it was a good choice. Pulse trains have hardware-precise timing, unlike most AO and DO tasks where data is written as scalar values. The different API helps just a bit to give the counter tasks a distinct look and feel.
Anyhow, back to your question. I can't test this now but I'm pretty sure this will be an appropriate way to think about your example. When you call DAQmx Create Channel, the pulse specs you specify are the ones that will be used unless and until you override them via DAQmx Write. Once you write an array of pulse specs, you're telling the task to replace its prior "default specs" with your carefully defined new ones. The task may set an internal flag for itself to know that it should pull its pulse specs only from the array you gave it.
I'd bet that if you the call to DAQmx Write, your task would run and use the pulse specs you defined at DAQmx Create Channel. The DAQmx Write should be seen as an override.
-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.
