6602 trigged counter pulse generation in a "for" cycle

[ampm]

Hi,

I have programmed counter 2 of the 6602 board for single pulse generation (please see the "task.JPG" file attached). The generation should start by a trigger (produced by the counter 3 of 6602) and there should be a certain delay between the receipt of the trigger and the pulse (I used "initial delay" input of the "CO Pulse Time vi" to specify the delay). I need to repeat the task described above several times. I do it using the "for" cycle in which I repeatedly start and stop the task ("cycle.JPG" attached).

I have the following problem:

During the first iteration of the "for" cycle the pulse is generated exactly after the specified "initial delay" time BUT during the following iterations the pulse is generated without any delay after the trigger is received.  What can the reason for this behavior be and which way can I program the task to get the desired behavior? I tried several ways but all of them failed...

Thanks in advance!

[Kevin_Price]

There is a known "issue" about this for triggered finite pulse trains -- see this thread for example.  That said, here are some possible workarounds:

1. Because you're generating 1 pulse per trigger, one simple workaround is to define low time == initial delay.  The first trigger will use the initial delay value, and all subsequent triggers will use the low time value.  If they're the same value, your problem goes away.

2. If you delete the call to DAQmx Timing, you won't cause the driver to use 2 counters together for 1 single pulse.  Instead, it will simply create a single pulse using 1 counter.  [Or maybe the driver is smart enough to do this for you when you ask for 1 single pulse?]

3. You can get retriggerable behavior in the hardware without stopping and re-starting in a For loop.  I know for sure it works for single pulse generation without any calls to DAQmx Timing.vi.  Before calling DAQmx Start, insert a DAQmx Trigger property node.  There are properties available there to set up a digital start trigger with "Retriggerable == True".

-Kevin P.

[ampm]

Dear Kevin,
thank you very much for your reply!

I followed your suggestions and everything now seems to work fine.
I must say that workaround with "low time == initial delay" is not an obvious one... 🙂

Thanks again!

[Kevin_Price]

Agreed that use of "initial delay" isn't the most intuitive.  It's a potentially useful addition, but I'd have liked it to work differently.  Of course, maybe my preferred way wouldn't be so good for others.

In older DAQ, you would define a "delay" interval and a "pulse" interval.  A separate setting was used to define polarity so you'd know whether you we making a high pulse (default) or a low pulse.  There was no such thing as an "initial delay" setting. 

When I first encountered the "initial delay" setting, I figured it would act as an extra amount of delay that would be added to the standard delay interval before the first pulse interval.  Instead it's a delay interval that takes the place of the standard delay interval.  I guess the advantage of this implementation is that the initial delay can be shorter than standard.  The problem with the implementation is that you almost always have to explicitly handle the initial delay rather than leaving a default.  Also, the default value of 0 isn't actually permissible -- it'll really use a minimum # of timebase cycles.  That # is 2 if I recall correctly.

There are 2 different alternate implementations I'd have preferred:

1. Delay before 1st pulse is sum of initial delay and standard delay.  Default value for initial delay is a true 0, but a minimum standard delay of 2 timebase cycles could still be enforced.  This way, you could ignore the initial delay input except for the specific apps where you use it intentionally.

2. Use initial delay in place of standard delay, but actually allow a true 0 value.  This would be great for triggered pulse apps where the counter output could change to its pulse state *immediately* after the trigger, rather than having to be delayed by >=2 timebase cycles. 

I also personally think that using the initial delay only for the 1st trigger in a re-triggerable task wasn't a very good implementation choice.  Based on the threads here, this has surprised several people and I don't recall anyone praising it as a good idea.  If it was a simple design decision rather than a hardware-imposed limitation, I hope NI will consider re-thinking this in future DAQmx drivers.

-Kevin P.