Precision with Multiple Counter/Timer cards and a DAQ

[John_P1]

The sample rate on the 6323 can be up to 1 MHz, which would give 1 us precision. 

In DAQmx you combine all of the clocked DO lines into a single task, but the idea was to have the offset pulses on separate lines.  Something like this:

Best Regards,

[TimmTheEnchanter]

Hi Spyrul,

It looks like that example John attached is simply the logic used to create the number of waveforms you specify. So you can use the output of this SubVI to connect to as many channels as you like (the number of waveforms to produce is a control specified in the VI as "Number of Channels"

Also, as John mentioned, the accuracy of the waveform generation on Port 0 of this device is 1 microsecond (1 us) because it operates off of a 1 MHz (max) clock.  You can find all the pertinent information for this on the specifications sheet for the 6323 (see page 5).

Regards,

Andrew

[spyrul]

Thanks for all the help, guys.  I'm going to be purchasing the 6353 just in case the project grows a bit.

Is this intended to produce the entire waveform or act as a buffer?  This may need to run for extended periods of time.

[TimmTheEnchanter]

Hi Spyrul,

This code produces the waveform.  You can then write it to the buffer of the DAQ device using the DAQmx Write VI within your LabVIEW code.  Running it for a long period of time shouldn't be a problem if you are generating the same waveform from the FIFO on the DAQ card.

Hope this helps,

Andrew

[John_P1]

While you can loop the waveform if you want to, the waveform that I was building accounts for the fact that the first channel starts earlier than the second (and so forth).  If you just were to loop this repeatedly you wouldn't get the result you're likely looking for (there would be gaps in the signal every time you re-generate the buffer).

You might instead want to break up your waveform into 3 parts so you can write just the periodic portion repeatedly:

Write the first and last segment only once at the beginning and end of your generation.  The middle segment would be written repeatedly inside a loop as many times as necessary.  You should use Non-Regeneration to prevent the regeneration of old data, and write continuously inside the loop.  It's a little tricky but certainly possible.

If your entire array of values can fit into memory then you wouldn't need to do this--it's only required if your waveform is so long that you run out of memory.

Best Regards,

[spyrul]

Yeah.  The waveforms will most likely be too long to fit into memory.  I'll see if I can make that 3 way split work.  I appreciate all the help.

-Adam

[spyrul]

At 10 channels, 500 Hz, 60000 pulses per channel (2 minutes worth of pulses), and a sample rate of 100000 Hz, it was able to generate all of the pulses into memory.  However, in the process of doing so, LabVIEW appears as "Not Responding", but then starts to work again. It seems as though every time I run it, it just keeps adding more and more into memory.  Is there a way to clear the memory used by the array at the start of initialization?  After a couple runs of this VI, LabVIEW is no longer usable until I restart it. 

[John_P1]

At array sizes that large you definitely want to take out the conversion from U32 to Digital Waveform--I had the conversion in there because digital waveform tends to be more straightforward for many people. There is an instance of DAQmx Write that handles the U32 Array case.

I was able to run the code with your parameters repeatedly with the above modification on my system (Win 7 32-bit, 2 GB RAM).  With too many applications open however I did receive a "not enough memory" error, so in the interest of stability as well as being able to output at max rate (if you want a higher resolution) you should probably consider breaking the waveform up.

Best Regards,

[spyrul]

Here is what I came up with for the pulse generation.  On the first loop iteration, it has the staggered start, and each subsequent iteration has the continuous waveforms.  When this stops, it doesn't have to stop staggered, it can just shut off.  Can this method still provide the timing accuracy I need? (5-10 microseconds)

So I would take this code, and create a digital out channel with a digital start trigger pointed to the rising edge of one of the counters?  In my loop would I just do a wait until task is complete to send the next section of waveform? The timing of this is where I'm getting lost. 

Thanks,

Adam

[John_P1]

The precision of when the transitions take place is just the inverse of your sample rate, so if you are updating at 200 kHz (or more) you would have at least 5 us precision, assuming the waveforms are built correctly.

As far as integrating the waveform generation with the DAQmx Task, I think it makes the most sense to use the waveform creation VI as a subVI.  You could have an input to the subVI select which segment of the waveform to generate (like shown below), or you could make an entirely new subVI for each section.

Some of the parameters above should be tied to each other, but I'm not sure how you want your user to be able to specify them (e.g. in terms of samples, number of pulses, seconds, etc.).

The size of the first waveform you write determines the buffer size, so make sure this is large enough so that you can keep up with the generation.  I'd suggest making the "Beginning" and "Middle" segments close to equal length and writing about 100-200 ms of data per loop.

I would also consider implementing the program as a state machine architecture but I'll leave that up to you to decide.

Best Regards,