Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

cDAQ-9181 with APIPA no longer detectable on network after power cycle

Solved!
Go to solution

Hi,

fair warning... This is not a clean cut question -> answer... I'm a little out of my depth with this network error stuff. Also, there is a high probably this is a network/windows problem and in no way caused by NI hardware or software. The main reason I'm coming here for help is because the operational staff onsite have assured me that they did not change their network config at all, which has left me at a bit of a loose end.

 

I'm using a cdaq 9181 deployed at a remote location, connected via a network I have limited visibility/control over and after almost a month of rock solid data acquisition it went dark.

 

There was a confirmed power cycle across the entire plant meaning the network + daq lost power for a period of time. Operations on site have resumed and are reporting no network errors.

 

What I need help with is exhausting all possible software/windows network config troubleshooting before I send someone out to inspect and factory reset the daq.

 

When first connected to the network the daq was detectable via niMAX -> add network device and appears to have assigned itself an Automatic Private IP Addressing (APIPA). address as: 

169.254.35.144

 

My knowledge of networking is limited (you can safely assume zero functional knowledge), from what I have read so far in the docs there are two potential solutions:

 

More background:

 

Errors I'm seeing:

  • when I try to add the device via <hostname>- 201252
  • when I try to add the device via ip: "the device you requested could not be found on the network"
  • when I ping the ip: timeout 100% loss

 

If I attempt to summarise this as questions:

  • I'm reluctant to play with ipconfig as it might interrupt other services running on the logging machine, but if someone confirms its a plausible solution I'll go ahead? 
  • Messing around with the registry isn't a problem, however I'm curious to know if it is plausible given that the daq was previously detectable?
  • what are the additional diagnostic steps I can take to get more information about what is causing the error?

 

Thanks for taking the time to read this and any help/suggestions you can offer

0 Kudos
Message 1 of 2
(2,322 Views)
Solution
Accepted by topic author Lyle_

Found the problem, someone had disabled dhcp on the logging machines second network card and inserted a static ip that created a conflict. 

 

Cdaq was still rock solid, this was entirely an operator error.

 

Setting the second network card to obtain an ip automatically fixed the problem. Alternatively setting a valid static ip address for the logging machine will also fixes the problem.

 

Message 2 of 2
(2,293 Views)