DAQmx DO Write Problem

[jamgar90]

I'm getting the following error from the DAQmx Start Task VI in my attached VI and I'm not sure what is causing it:

I'm attempting to initialize a single DO line for Finite Output and then initialize it with a single write.  I've looked at all the examples for the DAQmx Digital Output and can't see where my mistake is.

Hardware Configuration:  cDAQ-9178 chassis and NI-9403 DIO module

Software:  LabVIEW 2021

The attached VI has been saved for LabVIEW 2019.

I feel like I'm missing something simple, but can't figure out what is to save my life.

[Kevin_Price · Accepted solution]

Well, the error message explains it pretty clearly.  You've set up a hardware-clocked and buffered task and you only write 1 DO sample to the task buffer.  The error message tells you that you need to write more samples to the task before starting it.

Note: 2 might not be enough either.  If you know the pattern you want to generate, you may as well write all 100 samples you configured your Finite Sampling task to generate.

If you really just have 1 digital value to write, you should remove the call to DAQmx Timing, and use the 1 Channel 1 Sample Boolean version of DAQmx Write.  When you don't call DAQmx Timing, the task will be in software-timed "on-demand" mode and in that case you should start the task before writing the single Boolean value.

-Kevin P

[jamgar90]

Thank you for the information Kevin.  I was able to get it working with your suggestions.  The attached VI contains the working code.

A question about the timing function.  The 100 is wired into the rate input of the timing VI.  I thought the rate specified the frequency of signal generation and not the number of samples you intend to write to the buffer?  Would the "Samples Per Channel" input be the buffer size?  When writing elements, does the number of elements written need to equal the buffer size?  This is a side question since it doesn't apply when writing one element like I was trying to do.

[Kevin_Price]

Sorry, meant to reply to this long ago and it slipped off my radar.

1. You had two distinct 100 constants, one for the 'rate' input and another for the 'samples per channel' input.  Each was used independently for their distinct respective inputs.

2. The 'samples per channel' input to DAQmx Timing will:

• define the buffer size for a Finite Sampling task
• set a lower limit for the buffer size for a Continuous Sampling task.  DAQmx might make the buffer bigger than you specify.

3. When writing elements, the # samples written does *NOT* need to equal the buffer size.  In olden days of DAQ, that would have been a very poor and likely unworkable strategy.  DAQmx has smartened up over the years such that I *think* it now works pretty well.  But as an "old dog" I still feel safer with a strategy of replacing an entire output buffer by doing 2 consecutive writes of 1/2 buffer each.  Honestly though, it probably isn't necessary any more.

    More to the point, when running an app with a regularly varying output waveform, the key consideration for how much to write at a time doesn't need to care about nice divisors of the buffer size.  The main thing is that your app keeps writing to the buffer fast enough to stay ahead of the signal generation sample clock on the devive.  If you output at 10 kHz, you need to consistently deliver 10 kSamples/sec to the buffer with calls to DAQmx Write.   You might be able to do that by writing 10 KSamples at a 1 Hz rate, or you might need to do something like 500 samples at a 20 Hz rate.  Either one gives the needed overall 10 kSamples/sec bandwidth.

-Kevin P

[jamgar90]

Thanks for the information Kevin.  That makes sense.  I guess it's a fine line between starving and overflowing the buffer.  So far I haven't had an application that requires continuous output.  But, I feel like I at least now know enough to be dangerous.  Thanks again.