Error -50405 occurred at DAQmx Reserve Network Device

[Brett_Percy]

Hi all,

I'm testing out a new hardware installation for a client and my LabVIEW code has generated the error "Error -50405 occurred at DAQmx Reserve Network Device" - possible reasons are listed as "No transfer is in progress because the transfer was aborted by the client.  The operation could not be completed as specified"

The call to Reserve Network Device is the first DAQmx call in the LabVIEW code

This is using

- cDAQ 9181 ethernet carrier

- NI 9215 module

- NIDAQ 17.11f0

- LabVIEW 2017SP1 - 17.0.1f4

This error doesn't occur regularly, as far as I know it has only happened once but the hardware hasn't been in use a lot yet.  It's worked fine whenever I've tested it, it only seems to throw errors when the client is using it...

I'm fairly sure there is a direct connection between the laptop and the cDAQ 9181 with no other devices involved but I'm not 100% certain yet. I'm waiting for the client to get back to me with some more information.  

Has anyone seen this error for ethernet-connected devices?  I've found a few older posts about USB cDAQ devices doing this when other USB devices are plugged into the PC, possible making the USB system reset, but they don't seem super relevant here

I have also had the analog read start returning NaN after a short while, but I don't have any good error information about this apart from the recorded results

Cheers
Brett

[Brett_Percy]

OK currently the network includes a couple of HP switches between the cDAQ 9181 and the test laptop - this is a shared network so there will be some amount of other network traffic on it.

The final production network will be a direct connection between the cDAQ and a dedicated PC.  There will be two separate ethernet cards on this PC, one for the cDAQ and a separate one for the business network

Cheers

Brett

[Jerry_X]

-50405 indicates a bus connection issue, in this case, a network connection loss is probably the root cause. Removing any network switches in between the PC and the cDAQ is a good test. There is a periodic heartbeat from the host PC to the cDAQ. If the cDAQ does not respond to the heartbeat in time or if the heartbeat is lost in transit, then the host would see it as a loss of connection to the cDAQ.

[Brett_Percy]

Thanks Jerry,

So hopefully as the final network topology will be a direct connection with no other devices, this error shouldn't occur in production

This sounds like it would be a transient issue, so should I expect other DAQmx calls to work?  Also just retrying after this error should clear it

Cheers
Brett

[Jerry_X · Accepted solution]

If the network condition that causes the connection is transient, then the next time DAQmx Reserve Network Device is called, it will trigger a reconnection under the hood. And if the network condition is resolved, it will connect and reserve the cDAQ for use. The other connection loss possibility is that the firmware has crashed on the Ethernet cDAQ, and that is why it is not responding to the heartbeat. That is less likely. But in that case, the user have to wait for the cDAQ to boot up again.

Other DAQmx calls will not work in the connection loss case. To communicate with cDAQ, the host PC requires an active connection and reserve the cDAQ to lock out another PC on the network to use it.

[Brett_Percy]

Thanks for the detailed response Jerry, that clears things up a lot

Cheers
Brett