Getting status code -200587 - no other processes active

[JohnNavratil]

Greetings, all!

I have recently put a Fedora 7 system together with an older P-3 motherboard.  I am using NI_DAQmx (not "traditional"), and have received the following error on a couple of occasions both from within the test panels and from an NI provided example program...

DAQmx Error: Requested operation could not be performed, because the specified digital lines are either reserved or the device is not present in NI-DAQmx.

It is possible that these lines are reserved by another task, the device is being used through the Traditional NI-DAQ interface, or the device is being reset. You might also get the error if the specified resource is currently in use by LabVIEW network variables bound to the DAQ Channel, or if the DAQ Channel is being used in any OPC Client software.

If you are using these lines with another task, wait for the task to complete.  If you are using the device through the Traditional NI-DAQ interface, and you want to use it with NI-DAQmx, reset (initialize) the device
using the Traditional NI-DAQ interface. If you are resetting the device, wait for the reset to finish.
Device:  Dev1

Task Name: _unnamedTask<0>

Status Code: -200587


I have a PCI-6221.  I have seen this problem on port0 but not port1 and on port1 but not port0 within the test panels, on separate occasions.  When the problem appears, I verify that I don't have any processes which might be attempting to access the board and verify that 'nilsdev' shows the board is present.  The problem goes away after rebooting.  I do not discount a hardware problem with my motherboard as I don't know its history.

Can anyone explain under what circumstances one might legitimately expect this error?

Is there some means to "reset" the board without rebooting?

I am currently testing my software by looping pins on port 0 to port 1 through 10 KOhm resistors.  Any reason that this should present a problem?

Thanks!

-- John Navratil

[MissyS]

Hi John,

Normally you would see this error if you were previously accessing the board in Traditional DAQ or resetting the device. Since this is an M-series (and you're using Linux), you wouldn't be using this device in Traditional DAQ. As you probably know, Fedora is not a supported distribution of Linux, but we'll do our best to help you resolve this error. I would not expect sporadic misbehavior from a specific function such as this if it were the OS. Do you see this error message if you put this card in another system? Or another PCI slot? By trying it in another system, we can help determine if the error is caused by the board or by the computer (bad install of the driver, incompatibility, etc).

There is a function that you can call to reset the board. In LabVIEW it is called DAQmx Reset Device.vi, and in text based functions it is DAQmxResetDevice. If you call this function after receiving that error message, are you able to communicate with the board again without rebooting?

If you run an example program after receiving this error message, what function is this error returned?

I hope this helps!

Regards,

[JohnNavratil]

Missy,

Thanks for your suggestions.  I appreciate the reference to the API function for resetting the device.

The "sporadic" nature of the failure appears to be related to an adverse interaction between the test panels and the "ReadDigChan-ChangeDetectionEvent" example program.  It would make sense that if the change detection test program was attached to port0 that the test panels would not be able to as well.  If one starts "ReadDigChan-ChangeDetectionEvent" and then starts the test panels, this is the error which is displayed by the test panels when port0 is selected.  Similarly, if one start the test panels, selects the device ("Dev1", in my case) and then attempts to start "ReadDigChan-ChangeDetectionEvent", the same error is returned.  All as expected.

I observed that there were several times when I thought the test panels were not running that they were.  I now suspect I was not seeing what I was looking for.

Thanks!

-- John Navratil