PCI-6534 buffer underrun

[Mister_Rose]

I am getting a buffer underrun error when I am operating a PCI-6534 card. The card is supposed to have on-board memory, but this is still a problem. Here is what I am doing.

1) Read digital waveform from file into variable.
2) Create a DAQ task to handle things.
3) Load the waveform from the variable into the DAQ task.
4) Start the task (no errors)
Test sometimes works, sometimes not
5) Stop the task (error reported)

The code was working several weeks ago. As far as I know nothing has changed. Are there any tools that can help me find the problem (like who's using the bus, etc). Any other debugging ideas?

[David L.]

Hi Brian,

You are correct that the PCI-6534 has on-board memory, but this error can result from the data (mainly the size) that is being output or the transfer rate from PCI memory to on-board memory. The DevZone article ‘Maximizing the Performance of the NI 6534 Digital I/O Device’ has a few sections that relate to a buffer underflow and what could be causing your error. Please see sections ‘Possible Errors in Finite Operations’, ‘Regenerate Data from PC Buffer’ (2^nd paragraph), and ‘Possible Errors in Continuous Output Operations’.

If you are still getting the error, I would like to please ask for simple example code which will reproduce the error. Although you are getting a buffer underflow, a screenshot of the error will tell us the error number, where it is coming from, and typically a brief summary of how to prevent the error. I have attached an example error code for a buffer underflow. In this case, increasing my samples solved the issue. This is why I am asking for a simple program and error code – not so that we fix it for you and send it back, but to see what you are trying to accomplish, along with targeting where the error code is coming from and what may be causing it. After this, we can suggest solutions and go from there.

[Mister_Rose]

I didn't do a screenshot, but I did cut and paste the text. Here it is.

---

Error -200621 occurred at DAQmx Wait Until Done.vi:1

Possible reason(s):

Onboard device memory underflow. Because of system and/or bus-bandwidth limitations, the driver could not write data to the device fast enough to keep up with the device output rate.

Reduce your sample rate, or reduce the number of programs your computer is executing concurrently.

Task Name: _unnamedTask<2E>

---

Attached are the VIs I am using. The one of interest is the ROCKY_MOTOR.vi.

When I created the DAQ stuff, I basically used a DAQ Express VI and then I converted it to code when I got it working. It has been working for the better part of a year up until the other day. Now it always seems to fail. The waveform loads and starts fine. I do not get the error until I stop the task, which makes sense if it is having a problem during playback.

I have inserted delays up to 1 second before calling the "DAQ StartTask.vi", but I still get the error.

[Nick_F1]

Hi Brian,

It looks like you are doing a DAQmx write and for some reason there is nothing in the buffer when the task starts.  The first thing I would check is to make sure that there is data in the file that you are loading to make sure that there is data for the read to pass to the buffer.  One way to do this is to open the DAQ_LoadFile.vi, put a probe on the data line going into the DAQmx Write.vi and turn on highlight execution to see if data is being passed in there.  Since you are doing a finite write, it should put data in the buffer once and then write it out to the channel.

Are you placing the entire example that you posted in a while loop?  If that's the case, it looks it's possible that you are setting up the DAQmx Task and starting the Task multiple times before stopping the task.  This will cause undesirable behavior as well.

Increasing the delay before the DAQmx Start Task.vi shouldn't have an effect on the buffer since the data should be written pretty quickly.  Another thing you want to make sure of is that the Sampling Rate and the Samples per channel correspond with the amount of data that you are writing.  If the buffer is too large, then it can cause an issue.

I can't see the values that you have set for the DAQmx channel so I'm not exactly sure if changing those settings will help you.  Please give this a try and let me know what happens.  It might also be helpful to post one of your data files so I can try to reproduce the issue here.

[Mister_Rose]

I verified the data files by making a little program to read and display the waveform. I also refreshed the data files with a version from source control. I am still experiencing the problem.

The software I have written takes the file and sends it out a particular port. The data file and port are selectable, but other than that, the code is the same.

Some other things I have noticed and tried...

I noticed that the buffer underflow always happened on one particular channel, which was the second time that the waveform routines were used. Thinking that maybe it was a first run/second run problem, I changed my program to run the troublesome channel first. When I did that, the software always failed the first time and never failed the second time. This indicates to me that there is some issue with sending data out that particular port. Since the software is the same, and the software works fine on different ports on the same card, I am leaning towards the idea that perhaps that particular port on the card is bad. But it is bad in a way that does not show up in the diagnostic routines.

Should I contact my FAE to see about getting a loaner card, so I can swap the card out and confirm or eliminate it as a suspect?

Thanks,

[Nick_F1]

Hi Brian,

That is definitely a possibility.  If this setup was working a couple of weeks ago, and the file didn't change, then it is possible that there is something wrong with your card.  If you can somehow change out the card and test your system that way, it can tell us if there is something wrong with your hardware or allow us to eliminate that as the cause of your issue.

Please let me know what you find out.