I can offer one odd, obscure bit of info, but have low confidence it'll help because it wouldn't explain your CPU observation. Here goes anyway.
[The following was true the last I knew and I assume it still is. It's the kind of thing that seems susceptible to being fixed in more recent versions of DAQmx though.]
There are 2 main parameters to define in a pulse train. You can define them either in terms of frequency / duty cycle or in terms of low time / high time. A much lesser-known fact is that one of the parameters gets 2nd-class-citizen status. If you use a DAQmx property node to update only the "wrong" parameter all by itself, the change will be ignored until the next time the "right" parameter is also modified.
This has come up in past threads about pulse generation where frequency is the 1st-class-citizen and duty cycle is 2nd-class. Attempts to modify *only* the duty cycle get ignored. If the same old freq and a new duty cycle are *both* written, then the change takes effect.
You refer to a timing "delay", making me suspect a pulse train definition based on low time / high time. It may be the case that you're updating only the "delay" parameter via property node and that it may be the 2nd-class one. Try writing to both pulse parameters, even if the value you write to the other one is the same value it already had.
Again, I think your CPU observation tends to point toward a different issue than this. I think it's more likely that the high CPU and failure to update pulse delay timing are both *symptoms* of some other root cause.
-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.
