Hardware Timed Digital Pulse On Multiple Output Lines

[Lukin]

Hi All,

I am having trouble finding an elegant way output a hardware timed pulse across multiple digital lines on the same device. Essentially what I need is to what the Counter - Single Pulse Output.vi  shipping example does but across N number of lines.  Another way to think about it would be a digital output task that has a hardware timed start and stop trigger.  

I have attached a VI that does this (I actually have not tested it on hardware but I think it will do what I want).  It works by generating a waveform of all true values with one false in the last index that is the correct size.  I then use this waveform to do a finite output with a start trigger.  The issue I have with this having to generate a waveform with every point.  If its a short pulse its not to big a deal but if the user sets the task up to do a 30 second long pulse on 20 lines that will be a lot of data to generate.  

Another way I thought about doing this was would be to start a output task like I did in my example but with a single true value for each line instead of a waveform of values.  Then stop the task and restart it with a new start trigger (that is actually a stop trigger) and a false value.  Here I am relying on the driver maintaining a value once a task has stopped.  While I think this would work for long outputs I also need it to support short ones.  This software will run on Windows so I worry that if I had a 1 ms pulse I won't be able to guarantee the stop/start process would occur in time.  

I know having such a large range of supported pulse lengths makes things more difficult.  I just wanted to see if anyone knows of a better way.  At the moment I think I would use both methods and just use some logic to pick the one that makes the most sense for the given pulse.  Can anyone think of a better way to do this? 

[Kevin_Price · Accepted solution]

What kind of device(s) do you have available for this?  An X-series device (63xx family) has some capabilities that can give you both precise timing and memory efficiency.

Your posted code buffers and generates 10M digital samp/sec, presumably driven mainly by a need for 0.1 usec timing resolution.

A much cleaner method would be to define buffer contents *only* and *exactly* when any of the digital bits changes.  Then you define a buffered counter output task which generates pulses at those exact times, and use this counter output as the DO task's sample clock.

The timing resolution will be even better than 0.1 usec, and you only have to buffer and generate a small # of DO samples.

Note that because you'll have a variable-timing sample clock, you won't be able to use digital waveforms.  You'll need to define the digital states either in port format or boolean array format.

-Kevin P

[Lukin]

I guess I should have been more clear on what I am using.  Today I am planning to use this on a PXIe-6363, PXIe-6368, and PXIe-6365.  The code will go into our reuse library and once that happens I can't predict what it will be used on.  I can specify that it will only work on X-Series devices so lets assume that.

I don't have a hard requirement for the timing but your assumption of the timing is how the code got set up that way.  0.1 uS seemed like a number that would meet my needs and not be difficult to obtain/test.  

All that being said I just implemented what you suggested and it worked great.  For anyone reading this one thing that had me fooled for a bit was the Counter Time 1Chan NSamp instances of DAQmx Write.  Its input is an array of a cluster of two doubles called high time and low time.    I assumed that high time applied first and low time applied second.  It is actually the opposite in that the low time is first and the high time is second.  

Thanks again!!