We cannot deploy code to the robot. It works some of the time and fails most of the time. Pinging the bridge and cRIO gets reply at all times. Forum search is fruitless.
Our deployment window:
Initializing…
Calculating dependencies…
Checking items for conflicts. This operation could take a while…
Preparing items for download. This operation could take a while…
Deploying MotorControl.lvlib
…
Deploying 2010 Game Robot Project.lvproj
>>here, we get an alert: Waiting for Real-Time target (RT CompactRIO Target) to respond
>>With option: Stop Waiting and Disconnect
>>this does not go away, meaning cRIO never responded.
Deploying RT CompactRIO Target(failed to deploy target settings)
Deployment completed with errors
>>after we close the deployment window, we get alert:
Warning: Connection to the Real-Time Target has been lost.
Any subsequent attempts to deploy without rebooting the cRIO result in a conflict resolution window with message:
Access denied: This target is already in use by another project or host computer.
Rebooting the cRIO and retrying sometimes works and sometimes fail. Nothing seems to be different between the times that work and the times that don’t.
Are you connecting your programming computer via a wired network or wireless? If wired, try turning off any other network interfaces (including a wireless adapter).
Are you connecting your programming computer via a wired network or wireless? If wired, try turning off any other network interfaces (including a wireless adapter).
Does this occur when using a direct cable between computer and cRIO? Is it unique to the wifi setup?
Then, we tried Laptop-(eth)->cRIO, and the same thing occurs.
We’ve already updated our software to the latest version and flashed the cRIO afterwards. Would this have anything to do with using a computer other than the Classmate they gave us?
Thanks for your time!
EDIT: And yes, we do disabled other network interfaces. The problem is that pinging the target works 100% of the time, but deployment does not.
It never goes away. As in, we wait for a few minutes and the alert does not go away.
We’ve noticed something else too: This never happens on our first try, and a complete reboot of our computer, the robot, and our router fixes it, but we’d rather not have to reboot all our electronic equipment everytime we want to deploy code.
In the ‘Create new FRC Robot Project’ screen are you replacing the xx.yy values in the cRIO IP address field with your team numbers? I have found that if you forget to change those that you will get the error that you describe.
Merle Yoder
Mentor FRC 3146- The GRUNTS (Granby Robotics Under No Technical Supervision)
Coach FLL - Granby Red Blox - CT State 2nd place Champions Award
Good point. If you’ve already run the wizard, look at the project window to see if the cRIO target item has xx.yy or the team number. To change, right click on that line and choose properties.
ONLY 1 week left and problems are arising!! We are having a similar problem. When i build the project it works. When i try to deploy it, it gives me : Access denied: The project may be in use by host computer… BUT ONLY THE CLASS MATE IS CONNECTED. I tried restarting the classmate, the roobot, NOTHING WORKS. One other problem: when i try to “run as startup”, when its almost fnished … the connection is lost, and it DOES NOT GO AWAY!.. Plz help only got 2 days to finish robot cause we have too many holidays next week ( about 3>!!!)
The next time you get that message "Access denied: The project may be in use by host computer… ", try pushing the tiny Reset button on the cRIO itself. It’s a little black depression next to the 24v power connection.
When you get the “Waiting for Real-Time target (RT CompactRIO Target) to respond” message and it stays around for more than a couple of minutes. Just cancel the download and try again.
You seem to be having an intermittent connection problem, possibly due to a noisy connection.
Even though our team is using WindRiver, we’ve seen multiple times that what we originally thought was an intermittent network connection problem, was actually a power problem. Start from the battery, and give all power connections between the battery and the cRIO a quick shake to make sure they’re tight. Especially check the cRIO 24V connectors to make sure you don’t have too little or too much of the wire stripped and inserted into both ends of the screw terminals of the plug.
Secondly, we ran into intermittent communications problems after opening the cRIO and installing the gaskets provided this year. We ended up needing to remove them unfortunately. Once we did everything worked fine again. Opening the cRIO and blowing out any debris that might’ve accumulated from last year might help here.
We had the exact same problem (it would get stuck deploying the lvproj).
At first we could solve it by building and deploying the code (after that it ran fine).
At some point that also stopped working. Someone told us it might be because our flash code gets stuck doing some process. Anyway, we formatted, re-imaged the controller, ran super-simple code on it and now it’s fine.
I think it might have gotten stuck because the enable vision was on and the camera wasn’t connected. If I find out more about this I will post it here.
Kind of covered this, but thought I’d add a data point.
Our main code computer is a laptop running Windows Vista. We use LabVIEW. We also get sporadic disconnections and other network issues.
Particularly we get the stop waiting and disconnect panel while running or deploying. Usually it goes away after several minutes. Perhaps you need to wait longer.
Others have had good ideas, just thought I’d throw out a possibility.
We have been having this problem a lot lately as well. We tried the following:
power cycle power
reset cRIO
restart LabView
reboot the computer
On a hunch we checked for services. We restarted the services and power cycled the robot. This seems to be an effective work around for the problem. I am attaching a simple batch file you can run to restart the services.
NOTE: You will need to rename the batch file to remove the .txt extension.
After working successfully for a few weeks, I could not deploy code.
I re-imaged the CRIO and it would deploy once and then the robot code would never load in the dashboard.
Using wireshark to capture packets I could see that all the CRIO would do was to send an RST (reset) packet back to the driver station.
Looking at the netconsole CRIO app (Must be selected when re-imaging CRIO)
I saw a whole bunch of memory allocation errors about 10 seconds after CRIO reboot.
Startup Application: /c/ni-rt/startup/startup.rtexe
0xb75698 (Main Application Thread): memPartAlloc: block too big 108 bytes (0x8 aligned) in partition 0x32ddf8
0xb75698 (Main Application Thread): memPartAlloc: block too big 580 bytes (0x8 aligned) in partition 0x32ddf8
0xb75698 (Main Application Thread): memPartAlloc: block too big 108 bytes (0x8 aligned) in partition 0x32ddf8
0x80a7d8 (Exception Handler Thread): memPartAlloc: block too big 80 bytes (0x8 aligned) in partition 0x32ddf8
0x80a7d8 (Exception Handler Thread): memPartAlloc: block too big 80 bytes (0x8 aligned) in partition 0x32ddf8
0x80a7d8 (Exception Handler Thread): memPartAlloc: block too big 1024 bytes (0x8 aligned) in partition 0x32ddf8
0x80a7d8 (Exception Handler Thread): memPartAlloc: block too big 84 bytes (0x8 aligned) in partition 0x32ddf8
Turned out to be an FTP session that I started in the begin.vi was the issue.
It somehow used up the heap, still looking into it.
