While I had access to actual X-series hardware (PCIe-6341) this weekend, I followed up a little on a thread I was in to try to make sure that my proposed approach could work if there was a need for modifying the "initial delay" parameter. (In that thread, this need seemed fairly likely).
I quickly found that the initial delay parameter couldn't be changed while the task was in run state. Some further tinkering yielded several surprises. The attached LV 2016 code can be used to test things out on an X-series board.
Expectations / Actual Observations:
1. On the 1st trigger, delay is defined *solely* by initial delay, *NOT* low time/ticks. Over several separate runs while varying both initial delay and low Ticks, it was clear that this worked as expected. (Technically I always measured 4 Ticks more than the delay setting, but I'm content to chalk that up to 40 nanosec worth of signal propagation time in the hardware.)
2. On the 2nd and subsequent triggers, delay depends on setting for "Enable Initial Delay on Retrigger". When True, only the initial delay is used. When False, low time/ticks gets used instead. This checked out as long as I never updated the "low Ticks" value while the app ran.
3. Low Ticks value can be updated while the task remains in run state. Pulse behavior should only be affected by this change when "Enable Initial Delay on Retrigger" is False. Whenever I *did* update the low Ticks parameter, all subsequent pulses appeared to use the "low Ticks" value rather than "initial delay", regardless of the setting for the "Enable Initial Delay on Retrigger" boolean.
When changing the "low Ticks" value, I had to trigger twice before the measurement reflected the change. I'm not troubled by this behavior. I understand that the parameter I write gets immediately put into a "pending pulse spec" register, not the one that's active. The active specs need to get used for 1 pulse before my freshly written pending value moves into the active register. That's why I don't see it until the 2nd trigger.
Questions:
What exactly is happening here? Why does the "initial delay" behavior change when I update the "low ticks" parameter? Does the driver actually change *both*? Or why is the "Enable Initial Delay on Retrigger" setting ignored after I update "low ticks"? Shouldn't this be considered a bug?
Notes:
1. Tests run under DAQmx 18.5
2. In the "fixed-time pulse..." vi, only 'low Ticks' and 'high time (sec)' can be changed on the fly as the vi runs. All other changes require you to stop the vi, make the change, and rerun it.
3. In the "repeatedly measure..." vi, only the 'timeout' value can be changed on the fly.
-Kevin P