How do I program a NI 6602 card to send trigger pulses, one at each output port, triggered by an input trigger signal, using only one counter for each output port?

[Claes1981]

Hello,

I have managed to program a NI 6602 card in LabView to send pulses on three different output ports, one pulse on each output port (with individually chosen delays) for each input trigger pulse coming on a separate input port. It is the DAQmx Create Channel (CO-Pulse Generation-Time)-VI that I have used for this, see attached code. However, this VI controls both pulse delay and pulse width, and therefore uses two counters for each output port (although you only specify one counter in the VI input signals), as I understand.

In my application though, I only need to have the delay chosen, the pulse width can be arbitrarily short, and thus I should only need one counter for each output port. How do I accomplish to program this in LabView?

Best regards,

Claes

[picnic]

Hi Claes, 

I want to do something very similiar as well. I have not been able to find any solution for this so far. Did you find a solution, 

Thanks, 

B

[John_P1]

I don't follow--a single-pulse counter output only uses 1 counter.

If you are outputting a finite number of pulses (N > 1) then this uses 2 counters on the 660x devices.  A continuous pulse train only uses 1 counter.

Best Regards,

[picnic]

Hi John, 

You are correct in that a counter would be required for each pulse. My application requires that I have that I have an individually chosen delay on each pulse relative to the same trigger, however If use the 

DAQmx Create Channel (C0 - Pulse Generation- Ticks).vi it doesnt allow me to individually set the delay for each counter relative to the same trigger. 

I.e ctr0 delay = 0

     ctr1 delay = 10us 

Any suggestions, I may have overlooked an obvious vi maybe?

Thanks, 

B

[picnic]

Think I have found the solution. The DAQmx Create Channel (C0 - Pulse Generation- Ticks).vi uses the DAQmx Channel property node to configure the channels, however it defaults to configuring all channels to the same values. Adding in an additonal node and individually writing the values for each channel is the solution.. as best i can see anyway, 

thanks, 

B

[John_P1]

Use a separate DAQmx Create Channel for each counter output, you can set whatever initial delay you want (2 timebase ticks is the minimum though).

Configure a start trigger for each task to be the same PFI line.  Start each task before the external trigger occurs.

Best Regards,

[picnic]

thanks John, 

however this may result in timing issues from having two seperate tasks initated through software. using the work around i mentioned in my last post allows for a single task to be used as opposed to two. 

all the best, 

B

[John_P1]

Well you're welcome to do that--it will work just fine as long as you are configuring a start trigger.

<rant>

However, personally I really don't like putting multiple counter outputs in the same task.  I have seen so many people assume that the counter outputs would be synchronized due to having them in the same task when this is not the case (you need to configure a start trigger in order to synchronize the counter outputs even if they are in the same task).  This is the only case I can think of where multiple channels in a DAQmx task are not automatically synchronized.

As an example:

Running this on my PCIe X Series gives a measured 2 edge separation of 1 ms + {7.78 us - 10.11 us}.  This would likely be much worse on a bus with more latency (e.g. USB).

The resulting output is close enough to what you might expect that it might go unnoticed, but really these counter outputs are not synchronized and it would be easy to glance at the code and not even think twice about it.  For the small amount of extra work on my end to create a separate task for each counter, it really clears up some ambiguity about what the counters are actually doing.  For me it's worth it.

So again, for your case there really isn't a problem with having the counters in the same task since you are using an external start trigger anyway.  I have just gotten in the habit of avoiding doing this.

</rant>

Best Regards,

[arj]

a