My team tried re-imaging the cRIO first using the update that was installed with LabVIEW and the other NI equipment. An error occurred in the middle of imaging. I then realized we had misread the documentation and downloaded the newest update FRCLabVIEWUpdate1.0, as per the instructions on the WPI C++ page (we are coding in C++). I then tried to re-image the cRIO with the image installed with the update (version 2). This however continuously failed and generated an error saying that the IP of the cRIO could not be found.
Every time we loaded the NI cRIO Imaging tool, the tool would indicate that our cRIO was located at either 10.5.37.2 or 10.0.0.2. The IP seemed to switch every time I launched the Imaging tool (from 10.0.0.2 to 10.5.37.2 or from 10.5.37.2 to 10.0.0.2) on an apparently random basis. I’m wondering if this could have been caused by the abortion of the imaging process the first time we tried to image the cRIO (see the above paragraph). To test connectivity, command prompt was used to ping the cRIO. It always responded at 10.0.0.2, but never from 10.5.37.2.
The entire process was done following Chapter 5 Configuration of the documentation located at http://usfirst.org/community/frc/content.aspx?id=10934 yesterday (Dec. 2).
The laptop was plugged into the driver station (which was powered on) and the driver station was connected to port 1 of the cRIO. The laptop’s IP was set to both 10.5.37.6 and 10.0.0.6. Both did not generate any new success. A subnet mask of 255.0.0.0 was used at all times.
We are using a laptop with one ethernet port, built-in wireless (which was on at the time), and running Windows Vista. Other than disabling the wireless card next time I try this, do you have any suggestions?
During the Beta process, we had this problem on occasion and we think the problem is with your network, filtering out packets when the cRIO changes its IP address.
That the cRIO is changing IP addresses is an indication that you are partially connected and then the connection is dropped. I presume that you are team 537 based on the IP address that the cRIO is switching to.
When I saw this problem during the beta program, we determined that the router configuration was blocking the cRIO at the point where the cRIO reformatted and reset its IP address. For us this happened when we had the cRIO hard wired into the Linksys Router. We could work around the issue by having the cRIO use the wireless link. We also could work around the issue by having our laptop at the fixed 10.0.0.6 address and use a cross over cable to talk to the cRIO directly.
I don’t think aborting the imaging process is the reason for your problem.
I’ll check back later when I have a chance to review procedures with our Beta system vs. the documentation that has been sent out for the early adopters.
The problem was caused by the firewall. Disabling it solved all everything. Thanks for the help.
Was the firewall the built in Windows Firewall?
I seem to be having the same issue. We have Windows Firewall enabled at our PCs by default and there is a user group policy in place such that I can’t disable the firewall. I’m keen to know if the firewall you mention was in fact the firewall so I can support my request for a change in the PCs policy.
Thanks.
In the following post on the FIRST forums, they said it was the Vista firewall. http://forums.usfirst.org/showthread.php?t=10638
This is likely only an issue with formatting the controller, so it may be easier to convince them to change it on one computer only. However, you may have more troubles getting the IP addresses configured on your school’s computers. You may get to know the IT people very well.