Implicit buffered counter output task does not use initial delay

[John_P1]

Hi everybody,

Implicit buffered counter output tasks (the kind where you write a series of pulses to a software buffer) do not use the initial delay (I'm using an X Series).  Instead, the first low time in your array of samples is used as the initial delay, then the first high time is generated.  I had encountered this behavior in my previous role at NI but didn't quite appreciate the implication of it until now:

It presents an inconvenience for the case when a user (such as myself) might want to repeat an arbitrary sequence of pulses continuously.  I'd like to be able to specify the time between repeitions of my sequence independently of the initial delay.  The hardware does this for non-buffered implicit counter outputs (i.e. it overwrites initial delay with the desired low time in time for the next sample), so I don't completely understand why I don't have this capability with a buffered task.  I don't believe the inconsistency is documented.

In my case, the user can define a sequence of pulses and repeat it at some arbitrary rate for an arbitrary number of times (or even continuously).  It would be nice to implement this with one counter by calculating the appropriate low time for the first sample to ensure the sequence repeats at the desired rate.  However, in my case the time between repetitions could be several seconds and I can't tolerate having this delay before the very first pulse occurs.

This issue seems like the very reason that initial delay exists as a property, it's weird that buffered counter outputs don't use the property at all (non-buffered implicit counter outputs do).  Is there some way around this without using additional counters?  Is this a bug or is it intended behavior?  If it's a bug, can somebody provide a CAR ID for my own tracking purposes?

Best Regards,

[stilly32]

Hey John,

Good to see you back on the forums 🙂

This behavior was intentional - the initial delay input is part of the DAQmx Create Channel vi and due to the nature of writing to a buffer with the DAQmx Write, we disregard the pulse specs from the create channel (as noted in the manual - though admittedly it's pretty subtle).

As for your case, I'm not sure that I understand what you're trying to accomplish - can you post a pic/timing diagram of what you want to happen? It seems like it may be a case of just writing a new buffer after the initial buffer but I'm not sure if that will meet your needs.

Hope this helps,

Andrew S.   

[John_P1]

Hey Andrew,

Thanks for the reply 

The user of my application actually gets to set all the pulse characteristics themselves.  We are using the X Series as a triggering mechanism for a pulsed-power curing system--the user can specify an array of high and low times to be generated in sequence as well as a repeat frequency for the sequence.  Usually we'll end up with several pulses in quick succession with a long time in between them, something like this:

Conceivably I could implement the whole thing with a single counter by building the appropriate array of high/low times.  However, with no initial delay, the long gap between each pulse sequence ends up being the same sample as the very first low time (before the first pulse).  A delay on the order of up to 10 seconds before the first pulse is generated isn't very practical.  A software-timed write to the first sample wouldn't happen fast enough as I might need the new pulse characteristics as soon as ~10 us or so after the task starts.

I have ended up using a 2nd counter running at a fixed rate to re-trigger the finite arbitrary pulse train.  It turns out this isn't really a drawback for my application since there is a separate mode where the counter output has to synch up with an encoder so I would be using the 2nd counter for this purpose anyway.

Best Regards,

[stilly32]

Short of the tricks you could play with a second counter, the only other work arounds I'm coming up with are manipulating your write. If your user is specifying N pulse specs, and a delay between pulse trains, you could write a buffer N + 1 samples, where the + 1 is the delay + the high time of your first sample. You'd need to define how you would handle the low time for the first pulse (throw away or add to delay) since that leads. Since you're adding the delay to the write, this would give you time to write the next buffer, lopping off the first sample... repeat. You'd basically have an N+1 array and write that over and over again, but incrementing where you start from in the array each time.

Sounds like you have another solution that works though.

Cheers,

Andrew S.

[John_P1]

The ~100s of ms of delay is somewhat speculation, I'm not sure that I really do have a lower bound on the delay time between pulse trains.  If it was too short I still wouldn't have time to write (but then again if this were the case the delay would barely be noticeable at the start so I guess I wouldn't have to write anyway).  I'd end up with 2 different implementations depending on if the delay time was short (too short to write pulses reliably as the task was executing) or long (too long such that the delay is noticeable at the start), but this suggestion does seem workable if I absolutely needed to get this behavior with just a single counter.

A property to be able to enable initial delay for buffered counter outputs (similar to the "Enable Initial Delay on Retrigger" property) would be a more ideal solution, but this isn't holding up my application or anything--I'll probably be using 2 counters regardless since I have to use the 2nd counter to trigger the 1st anway in other use modes.

Best Regards,

[stilly32]

Thought of this while driving home: instead of writing a buffer size of N + 1, write a buffer of (N + 1)*N. That should repeat correctly and you'd only have to do the write once. It would still be some effort to put the samples together and you're looking at a potentially large write, but it should work for all situations.

You can always put in a post to the idea forum for the functionality you're asking for.  

Cheers,

Andrew S 

[John_P1]

I can generate my pulse train in continuous mode so there might not be a finite number of repeat cycles.  I'm not 100% sure if that's what you meant by (N+1)*N or not, but if I'm running continuously then a single write wouldn't be good enough (unless I did something goofy like write a finite buffer that would be so large that it is practically continuous, but without a maximum run time, minimum pulse widths, or maximum repeat frequency it would be hard to justify the claim that this would be a robust solution).  I could probably do a hybrid approach where I write a buffer that is long enough to ensure I have time to re-write the first sample before it is reached again and then from there just repeat continuously, but this seems unnecessarily complicated and I probably won't ever go this route.

I went ahead and posted to the idea exchange here.

Best Regards,