Alexander,
I'm interested in figuring out whether I'm wrong about the "restriction" I referred to. I'm pretty sure that it *was* true for continuous pulse trains back around DAQmx 8-point-something. I'm not quite as sure whether I ran into it with a 6602 or an M-series board.
However, I'm not sure I was entirely clear about how this "restriction" (if it exists) works. You commented that you doubted that you coincidentally updated your pulse properties during the 24 idle usec rather than the 975 usec low time. My understanding of the "restriction" is that it doesn't matter when you change the pulse property values as long as you've already generated at least one pulse with the previous values.
I've thought that to be a true restriction for continuous pulse trains and remember producing an error when I tried to change the pulse specs too rapidly. I *do* now wonder whether there was a similar restriction for retriggered single pulses. And either way, I wonder whether that restriction has gone away either with a newer DAQmx version or with newer counter chips like those in the X-series boards.
In the interest of learning things while not having hardware available to experiment, let me describe the way I've long believed that restriction to work:
1. The counter generates pulses based on the pulse count values that are in its active registers. These counts represent the low and high times for the pulse. Our code never writes to these registers directly.
2. There's another pair of "pending" registers that our code *does* affect. When we write to these, a flag gets set somewhere (driver? board chip?) to tell the board that there are new values to load.
3. At the next appropriate opportunity (not sure when this is, but likely exactly once per pulse cycle), the board will check that flag and if the flag is set the board will transfer the values from the pending registers into the active registers.
4. I *think* that the flag won't be cleared until after both pending registers get copied to the active registers. I'm guessing that this process must take 1 cycle because they can't both be copied at once. You'd have to write the low time while the high time is counting down and write the high time while the low time is counting down.
5. Any attempt to write to the pending registers while the flag is still set produce an error
6. After the flag is cleared, we are allowed to write to the software registers again. Any time, without regard to the phase of the pulse(s) being generated.
7. So, since the flag doesn't clear until after producing 1 cycle of the new pulse times and since we can't change the software register until after that, I *think* that the 2nd set of new pulse times can only take effect after at least 2 cycles of the first pulse times.
After all that, my question is: do you know whether you were ever able to create 3 consecutive retriggered single pulses with different pulse specs for all 3? I'm beginning to think that might have *always* been possible. The way I outlined my understanding of things above, it seems like the pending registers could almost always be moved into the active registers during the idle time between the end of one pulse and the receipt of the next trigger.
-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.
