-201388 "Network device not reserved for this host"

[FlamingYawn]

I have several DAQmx tasks executing on a 9188 cDAQ ethernet chassis (LabVIEW 2011, latest drivers).  Everything will be running fine for hours, and I will get a -201388 "Network device not reserved for this host" error from all of my running tasks.

The only other devices on this private network are an ENET-232 (I'm talking with one serial device) and a PLC (which I am communicating with over TCP Modbus).   There are no other PCs on the network.  This has happened at least a dozen times, after running for hours or days without a problem.  After going in to MAX and re-reserving and sometimes resetting the cDAQ everything works again. 

What could possibly cause the cDAQ to become unreserved?  

On one occassion my Modbus communication stopped working.  As soon as I unreserved the cDAQ chassis it started working again.  What could cause this to happen?  What protocol is the cDAQ using to send its data back to the host?  How could this be conflicting with my Modbus TCP communication and could this somehow be the cause of the chassis becoming unreserved?

[bstreiff]

The cDAQ-9188 uses a propietary data streaming protocol on port 31415. Modbus seems to be on port 502 (looking at the Modbus FAQ); they shouldn't conflict at all.

How are IP addresses assigned on your private network? Are you using static addressing? DHCP? Link Local (also referred to by Windows as 'Automatic Private IP Addressing')?

Is the cDAQ-9188 powered continuously? (Although power loss should not cause you to lose a reservation, it would cause disconnection.)

[FlamingYawn]

Thanks for responding so quickly.

I agree there should be no conflict, but that's what appears to be happening.

The IP addresses for the four devices on this network are all statically assigned by me.

The cDAQ is continuously powered; it's tied to the same power as the manufacturing process.  The cDAQ still shows up in MAX immediately after the problem occurs.

Just now I was logged in to the host computer via Goto Meeting (basically remote desktop).  Right when I logged off, the chassis became unreserved again.  This time it threw error -50405: "NI Platform Services:  No transfer is in progress because the transfer was aborted by the client. The operation could not be completed as specified."  Any ideas here?

[bstreiff]

Hm. If the addresses are all statically assigned, then there's no opportunity for them to change periodically (as is possible with DHCP/Link Local). So that's out.

The -50405 and subsequent reservation loss make it sound like an issue with the device firmware restarting, though I'm not sure what GoToMeeting would be doing to trigger that. Does using GoToMeeting always trigger this, or was that just coincidental?

What version of the cDAQ-9188 firmware (the latest is 1.2.0) and what version of DAQmx (latest is 9.4.0) are you using?

[FlamingYawn]

GotoMeeting was probably coincidental.  I tried to reproduce, but it stayed reserved when I closed it.

DAQmx 9.3.5

cDAQ-9188 firmware 1.1.0f0

I'll update and see if that helps.

[juergen]

I have the same problem with the error  -50405

I found that the probleme is a short disconnection from the network

I solve the problem in LabVIEW with the VI  "Reserve Network Device"

Is that a LabVIEW problem or a windows ?

I use version of the cDAQ-9188 firmware1.2.0f1and version of DAQmx 9.3.5f2

Jürgen

[FlamingYawn]

I was seeing error -50405 periodically as well.  I've been working directly with R&D to solve this issue.  They put some connection fixes in DAQmx 9.4; I haven't had any disconnect issues since installing it.  Time will tell.

Robert 

[juergen]

what do  I have to install this one

NI-DAQmx Run-Time Engine - (Core)

or this one

NI-DAQmx Run-Time Engine - (Configuration with MAX)

Thanks Jürgen

[juergen]

OK

I found the new Verion 9.5

I will test this version and see what is happening

Jürgen

[FlamingYawn]

Yes, sorry for the typo; the new version with the connection fix is 9.5.

Robert