Determining when the buffer is empty in "Non-regeneration" mode

[BertMcMahan]

I have an analog output task that needs to run indefinitely, and needs to be modifiable on-the-fly by the user, so I'm using analog output in non-regeneration mode. This works fine, but I need to be able to gracefully stop the generation; when the generation is done, I need to smoothly move back to 0V on the output. The waveform is a sine wave with some offsets. I'd like to be able to stop the output at the end of the current output buffer.

In this mode I can't use Wait Until Done, so I'd normally just stop filling the buffer, then wait for an Underflow error; I could clear it, then write one final "smoothing" waveform to get the output where I wanted it, then I'd be done- but I'm not seeing any underflow errors showing up in the simulation, nor can I find the property node "Next Write is Last" to try to work it out that way- it's just not there anymore.

I don't have the hardware in house just yet so I'm using a simulated DAQ card. Do simulated cards not throw underflow errors? It seems to me right now that the task just idles until it sees a new wave to transmit, not throwing errors or even warnings to let me know the buffer had been empty.

To test this I loaded the shipping example "Voltage- Non regeneration- Continuous output" and added a "Wait" function, ensuring that 1 second of data was written to the output buffer every 2 seconds. I should have seen a warning or something that the buffer was empty- but I got nothing.

Do simulators not have this feature built in? What happened to the "Next Write is Last" DAQmx Write property node? Is there a way I can tell when the output buffer has written all of the most recent samples, so I can stop it gracefully? I'm using LV2016; the last time I did this was on a much older system, so it seems that things have changed- but I can't find any patch notes regarding this.

[ybalam · Accepted solution]

According to the help documents here and here looks like the "Next Write is Last" property disappeared sometime between the June 2015 and February 2016 releases of DAQmx. I'm unsure why it disappeared, though, there's not much documentation I've been able to dig up surrounding where it went.

As far as if simulated devices throw under/overflow errors or not, I would think that since an underflow error refers to specifically the device's memory that they wouldn't throw those errors. I might try using the Timing Property "SampClk.UnderflowBehavior" and setting that to Halt Output and Error in your simulated environment to see what happens? Your strategy sounds like it would work with a device in hand, though.

[BertMcMahan]

Hi Claire, thanks for the reply. Sorry for my late response; I've been out of the office for Christmas.

That's interesting that the NextWriteIsLast property is gone, but at least I can confirm for now that a physical DAQ device will throw the underflow error as expected. This is good and will let me write a very small sample to the buffer, making sure it ends where I want it to be, then I can wait on the error.

Again, this error does NOT present itself with simulated devices, which threw me off.

Another interesting thing is that for whatever reason I cannot select "SampClk.UnderflowBehavior" from my DAQmx timing property node. This is all I get:

I wondered if it was a version incompatibility, but loading the local help files for DAQmx 16.0 seemed to confirm there should be a few more properties that I'm just not seeing on the list.

At any rate, now that I'm throwing the error properly I can move ahead. The main issue was knowing that the buffer ended at a "known good" state. It is acceptable in my application to not stop instantaneously, but still it would be nice if there was a way to ask the device what the most recently written value was to its onboard DAC. It would be nice if I could abort the task instantly, ask the device where it is, then generate a "ramp down" from there to 0 V. Unfortunately there's no way to do that as far as I can tell unless you use an analog input channel to do so. Though I know there are internal routes that let you measure it without extra wiring, I can't always guarantee that the analog input section of the DAQ will be available.

[Kevin_Price]

I don't think there's a way to query an AO task to find out the last DAC voltage(s) generated or the present value at the terminal(s).  I know there didn't used to be, maybe it's changed?

I'd resort to keeping my own circular buffer of AO values in software.  I'd make it the same size as the DAQmx task buffer, and when I needed to stop the AO task, I'd query for the "TotalSamplesGenerated" property.  That'd let me calculate an offset into my circ buffer to find out "where I left off", and then gently ramp the output to 0.

-Kevin P