I am getting an underflow error when I want to stop a continuous double buffered analog output task. I would like to have the error stop the task, but don't want the pop-up message. Is there a way to disable the pop-up.
Hvae you tried manually handling the error in your code? If you are unfamiliar with try-catch blocks, this Microsoft Knowledge Base article should help explain the concept. In the catch block of code, you can specify that you want the task to be stopped without having a popup message.
First, thank you for the response.
So you are saying that the DAQmx drivers are throwing an exception? Do you know of any documentation which tells me when exceptions are thrown?
I find it puzzling that an exception is being thrown that can be caught by my code. For performance reasons, maybe not that important in this case, I have no exception handlers in this code. If an exception was in fact being thrown it should cause my application to actually crash.
Some background on my problem and the apparant total lack of a way to handle it with the NI drivers.
I am running a double buffered analog output on M-Series devices. My buffer is 250 samples long. I am running an algorithm which "shapes" the command and constantly updates the buffer. All this is fine unless the user wants to stop.
With the M-Series devices all the functions which were apparantly written to "ignore" or "disable" underflow problems are not supported. The only way to stop the output is to stop the task.
The problem arrises that I don't know what the actual last written value to the DAC was. There does not seem to be a way to get that value from the drivers. So the actual value being output on the DAC and the value displayed, stored in the software are not the same.
I thought I might be able to keep a "copy" of the FIFO in software and ask the driver what position the next write will be at in the buffer. Then I could look up the voltage value that should have last been written in my own copy of the FIFO. Two problems. The function call that is supposed to return the write position returns nonsense values and there is a time lag between when I ask what the write position is and stopping the task so the next write is out of date by time I stop the task.
I finnally gave up and just make sure I completely fill the FIFO with a constant value so I can guarantee I know what is being output on the DAC when I stop the task.
I'm not certain that an exception is being thrown, but I did not have much information to go off of. There are many potential reasons for this type of behavior, so we'd need to look at more details to figure out what's going on. Exactly which device(s) are you using, what error code is presented to you, which ignore/disable functions did you look at, and are you doing continuous or finite generation?
Not a bad workaround you've got there. Take a few more deep breaths and we'll see if we can figure something out