Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Retriggerable single pulses -- EXACT behavior of initial delay, low time/ticks?

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 1 of 2
(2,260 Views)

While waiting for a definitive answer from someone in the know at NI, I have at least a speculative hypothesis about what's going on.  The background context is gonna require a little ride in the wayback machine, back to pre-DAQmx days and E-series 24-bit DAQ-STC counters.

 

Back in the day, the traditional NI-DAQ driver exposed more of the "bare metal" details of working with counters and also tended to demand that you learn more about those details.  One of those details (at least for the counters of that era, but I suspect this has continued forward) is that there were 2 sets of registers available for pulse specs.  2 were live and actively being used for pulse generation.  The other 2 were the alternate "pending" specs, ready to be used for live generation on command.  I referred to this briefly in my original post above, the 2nd half of this article talks about it a bit, as does this nearly-20-year-old post of mine. 

 

 As DAQmx came along, these low level details were no longer made available for direct manipulation (here's a good thread with some NI-insider answers).  And now here's my hypothesis:

 

Up in the DAQmx API I define Initial Delay, Low Ticks, and High Ticks.  The way these get used down at the low level is that Initial Delay and High Ticks go into the active pulse spec registers.  And Low Ticks and High Ticks go into the "pending" pulse spec registers.

 

When "Enable Initial Delay on Retrigger" is set False, the first trigger causes the pending specs to become the new active specs.  So the first trigger waits for Initial Delay, all subsequent triggers wait for Low Ticks.

 

When "Enable Initial Delay on Retrigger" is set True, the trigger no longer brings in the pending specs to be the new active specs.  It just keeps the original active specs in place.  So every trigger uses Initial Delay.

 

UNTIL I write the Low Ticks property.  This immediately updates the value held in the pending specs *AND* sets up a condition where *after* the next trigger and full pulse, the pending specs become the new active specs.  Thus, any subsequent triggers use the updated Low Ticks value.

 

That's my speculative hypothesis.  DAQmx simplified the API.  The standard description about the behavior of Initial Delay and Low Ticks under retriggering holds true under the vast majority of conditions.  The exception I think I've found is an unusual corner case involving both retriggered pulses and a desire to change the pulse specs on the fly.

    As it happens, I would say that the behavior I observe is *desirable* as it demonstrates that there actually *is* a mechanism available to accomplish that unusual use case.

 

Can anyone from NI comment on all this?  And if you do read this topic, let me again register my opinion that you should keep the behavior and update the docs rather than vice versa.

 

Further note: I've looked at this *only* on a PCIe-6341.  But I think this stuff is basically a non-issue for older boards that don't even support the "Enable Initial Delay on Retrigger" property.  As I understand it, such boards never re-use the initial delay value and always switch over to Low Ticks anyway.  Thus updates to Low Ticks would in fact get used while also being *expected* to get used.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 2
(2,191 Views)