PCI-DIO-32HS (PCI-6533) setup problem

[CFGVision]

Hello
I am in the process of setting up a Windows XP-based Labview 7.1 system and I am encountering a frustrating problem. Just to make sure I provide enough details, I'll describe what I've done so far, step-by-step (sorry if this gets tedious):
First, I installed Labview and the NI-DAQ 7.3 drivers. I powered down the system and installed two PCI cards: a PCI-6031E and a PCI-DIO-32HS (PCI-6533) in PCI slots 1 and 2, respectively. I powered the system back up, went into MAX and configured the cards as follows:
PCI-6031E: Device 1; AI: Polarity/Range=-10.0V - +10.0V, Referenced Single Ended; AO: Polarity=Bipolar; Accessory=SCB-100
PCI-DIO-32HS: Device 2; Accessory=SCB-68

I then started up Labview and ran my VI. This VI has been in use for 2 years now on the same NI hardware, so it's been well-tested and works great on other systems. However, when I run it on this system, the PCI-DIO-32HS spits out an error, with "Digital Buffer Write" as the source, and with a code of -10843 (buffer underflow).

What's interesting is that I had this exact same problem when I was setting this system up in Mac OS 9. That time, I realized that the problem could have been due to the fact that I installed the hardware before I installed the software, so there may have been problems communicating with the device. By uninstalling everything and then re-installing it in the proper order, I solved the problem and was able to run the VI flawlessly. I'm assuming that these two problems are related in their nature, but this time around I was very careful to make sure that I did all of the setting up properly (I did it twice just to make sure. It did not work either time), so I'm not sure what could be the exact source of this one.

Please let me know if you have any ideas as to what the source of this problem might be. Like I said before, I think there's probably a resource problem that's causing a communication failure which results in no data being sent to the DIO card (hence the buffer underflow error), but I can't figure out where to look for such a problem or how to fix it. Obviously, I'm rather new to Labview and everything about it, so the help is greatly appreciated.

Thanks!

[AlanArmstead]

Initial information was great. You mentioned that you have set up the boards in MAX. Did you run a test panel for the DIO-32HS board in MAX? Can you successfully do digital input/output in the test panel? If you are able to communicate with the board in MAX, the problem can be isolated to LabVIEW. Have you been able to run any simple example programs with the DIO-32HS board? What else is going on in your program besides the digital output? Please provide this additional information so we can narrow down the problem.
-Alan A.

[CFGVision]

Hi,
Thanks for the reply. I have run the test panels, and I have not generated any errors in them. I've verified that I can definitely do output, because LEDs on my equipment turn on when turn on output on certain channels.

So, I agree that the problem lies in the VI. I was not the author of the VI, however, so I'm not sure where to look. The author was also kind enough to have not provided any documentation. What would be a good example VI to run? I've never looked at any of them.

As for how the program works, I don't believe there's any actual input coming back into the DIO-32HS. The system is used for electrophysiology. The DIO sends a signal to flash LEDs at given intervals. Electrodes then pick up an electrical signal from the retina of a mouse, which is sent to the DAQ card and written to a file. I have run complete tests, and proper data files were generated and contained expected voltage values. The only part that's not working right now is that the LEDs aren't flashing due to this error.

I did some digging around in the program, but I couldn't come up with much. I verified that the program expects the DIO card to be Device 2, so there's no problem there. Aside from that, I couldn't find anything that seemed like it would apply.

Thanks for your help! I have no experience with Labview, yet I've found myself placed in the "Labview expert" position over here, so I've kind of been forced into a sink-or-swim type crash course where I learn as I go.

[AlanArmstead]

Here is a simple digital output example for LabVIEW 7.1. There are several other good examples in the LabVIEW Example finder (Help>>Find Examples). If this or any other example works, you might want to look at the similarities/differences between it and your program. Because of the fact that your program has worked on other machines with similar setups, it would lead me to believe that the error you are receiving is due to differences in speed of the machines. Buffer underflow/overflow errors often occur when the processor is executing the code faster/slower than the LV program expects it to. I'm going to take a stab and guess that there is probably some digital output taking place in a loop in your program. You might try to put a delay in that loop (or increase the delay if there already one there). Hope this information helps!
-Alan A.

[CFGVision]

I tried the example VI that you provided and everything seems to work just fine.

Something that I failed to point out, but will help elucidate things just a tiny bit, is that this problem has happened every time that we've tried setting the system up on computers that are faster than what we've been using.

The entire VI is rather large, and it's also password protected, so I'm not sure if I can post it (I'll have to check with my boss when he returns next week). I have attached a screenshot of the problematic DIO section of the VI. I've been able to narrow down exactly where the error is arising, however, it does not seem to make much sense. As you can see in the screenshot, the DIO config module is not outputting any errors, yet the Digital Trigger Config module, which is directly wired to the DIO config, is receiving the error in question. So, maybe I am missing something, but this error is being generated in between two VIs? Hopefully this screenshot is useful, at least until I find out whether or not I can post the VI.

Thanks

[CFGVision]

seems the screenshot didn't attach properly...let me try that again.

[CFGVision]

hmm...disregard that last post. there were some shift registers that i hadn't noticed. so, it's back to square on for me. i have no idea what's going on.

[Sean_C.]

A Buffer Underflow Error occurs when your device is writing data faster than the PC can provide that data. You might want to try putting a delay in your Digital Write Loop. Another way to work around this would be to write larger chunks of data at a time. You could also try increasing your buffer size.

If none of these steps help, try isolating the problem area of the code. If you can reproduce this error with a small piece of example code, I would be glad to take a look at it.

Let me know your results.

Sincerely,
Sean C.

[CFGVision]

i'm still in the process of trying out your suggestions. however, i was thinking about something. this program was originally written for a mac, and i noticed that the digital buffer needs to be filled on a mac before the digital output operation is performed. could it be that the program is written to take this into account, while the hardware is not expecting it? i.e. the program is written so that it collects an entire buffer worth of data before it actually does the digital output, however the hardware is just doing the output every so often no matter how much is in the buffer, thus appearing as if the computer is not writing to the card fast enough. it doesn't make any sense to me why a faster computer would experience buffer underflow errors. it seems to me that, if anything, it should be sending data *faster* than the card can handle.

thanks for your patience with me. i'm literally learning labview from scratch by having to solve this problem. i'll still look into your other suggestions...

[Sean_C.]

Hello,

The DIO operation will be the same for a PC. Meaning that you do have to write to the buffer before calling DIO Start. I agree that moving the application to a newer, faster computer should not result in a buffer underflow error. However, since that is the error you are receiving, we should try to track down the cause.

Please keep me updated on your progress.

Sincerely,

Sean C.