08-26-2018 09:19 PM
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:
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:
If I attempt to summarise this as questions:
Thanks for taking the time to read this and any help/suggestions you can offer
Solved! Go to Solution.
08-27-2018 09:26 PM - edited 08-27-2018 09:28 PM
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.