Unable to connect to Real Time Target

Some of this is copy-pasted from my last thread, but it’s still relevant to this problem.

We are a rookie team, and out group has been attempting to get both Java and LabView code onto the robot. We’ve done many suggestions found on the forums and followed the step-by-step instruction guide for both.

For each of these, we used the correct imaging for each code and set it up for our team IP (I.E., for the robot, for our netbook).

{while trying Java}
I’ve taken down every single firewall I can find, opened every port, and wrote a new “rule” for outgoing data as found in a forum post. This did not work. I uninstalled and reinstalled Netbeans modules, as recommended in the forums. We performed updates and re-updates. With our Driver Station, we have greenlights for Communication and Joysticks. When we tried to run the Java, as outline in the FRC step-by-step instruction guide, we had an error code which, at the top, essentially said there was a communication problem.

{while trying LabView} [currently trying labview exclusively]
Deployed every way it said to in the instructions, all the other settings are the same, and no dice.

All lights are green on the driverstation, but every time we build, “run as startup”, or deploy any part of the code (or all of it), we get the same “Unable to connect to real time target” response.

We thought yesterday, when we got all green lights, that we’d fixed the issue. However, the only difference between Java and LabView is this false positive. Any suggestions?

When you generated the Labview project, did you give it the IP address of the cRIO?

When configuring your projects with the target cRIO’s IP address, try it without the leading zero. I haven’t done any rigorous testing, but there is evidence to suggest that might work where doesn’t.

I went through http://www.usfirst.org/sites/default/files/uploadedFiles/Robotics_Programs/FRC/Game_and_Season__Info/2013/GettingStartedwiththe2013FRCControlSystem.pdf

for the second time, this time configuring everything for The only change is that, when building our LabView code, it restarted the cRIO first. Communication is lit, Joysticks are lit, and Robot Code is lit whenever we ran robot main or “run as startup” for the deployment. The Driver Station is enabled, but none of the joysticks do anything.

Right clicking on “Basic Move.vi” and selecting “Deploy” allows it to go through a long deploying something or other. However, robot code light is red.
Right clicking on FRC Robot Boot-up Deployment and selecting “Deploy” causes it to do the deploying, but shorter, then have a red light on Robot Code still.
Right clickingon RobotMain.vi and selecting Deploy causes, once more, lots of deployment and results in a red robot code light.
Right clicking on RobotMain.vi and selecting Run causes lots of deployment, a launching of the Robot Main.vi window (with a large Finish button), and a green light on robot code. When I hit “enable”, neither joystick does anything and there is no noticable effect.
Right clicking on BasicMove.vi and selecting Run causes it to “Load” a variety of what I can only assume to be modules. Then it deploys stuff, I hit enable (Teleoperated Enabled), and no joysticks do anything.
Right clicking on Build Specifications and selecting “Build All” causes it to initialize a build for a large amount of time, then "the build is complete. You can locat the build at C;\users\developer\documents\labVIEW Data\2013 Robot Project\Builds
I’m not sure if I’m supposed to do anything with that last build, or if I’m deploying the code wrong or something. I made this very detailed so hopefully it’ll be more useful than the array of “robot code isn’t working help plz”.

Edit: Upon closing LabView for the day, I got “During the last run of LabVIEW 2012 one or more internal warnings were detected and logged.”
Report ID: 61743539-83c4-4e8d-af0f-e67db3182bf2

The robot safety requires that RobotMain, or more specifically, the Start Communication VI is running, before it will enable the motors.

One typical deployment for execution is to Open RobotMain and push the run button. This will be in the debugger, so you can probe, pause, breakpoint, etc.

The other is to right click on the Build Spec and Build and when that complets, right click and Run as Startup. This is not really needed until you are basically happy with code and want to compete or practice and have the robot boot into your app.

As you open examples, you’ll notice that any which operate motors also contain the basics of RobotMain.

Greg McKaskle

Before you can Deploy code to the cRIO, you need to Build it. The result of the Build will be a file that you can then Deploy.

Except that you really shouldn’t use the “Deploy” command. If by some chance you didn’t select the checkbox to “always run deployed code” when you reimaged the cRIO, code that you Deploy won’t actually be run when the cRIO starts up. To ensure that your code gets run on startup, use the “Run as startup” command instead of the “Deploy” command.

The general routine is to Run the “Robot Main” vi during development. When you’re satisfied that what you’re doing works and you want to put the code on the robot more permanently, Build then Run as startup.

We’ll still have to figure out why the joysticks are having no effect, though. What is your Teleop code supposed to be doing?

I am the other programmer for our team and from what i undertand of the tutorial pdf that we used it should simply move the robot forward and backwards

Where did you get the PDF? I’d like to take a look at it. It might not match the 2013 competition robot project framework that you really should be using.

I’m not sure if we’re experiencing the same problem or if the OP has a different problem but I might as well bring it up in this discussion since it is related to the OP’s problem.
It seems like we experience the same problem about this time every year with the cRIO comms. It is now happening again and I’m at my wit’s end trying to find the cause.
Up until now when we hit the run button (LabVIEW) in Robot Main the code would deploy to the cRIO with no drama (unless we leave the network cable off). Last night the programming team reports that now the deployment process stops at “waiting for robot target to respond” and stays there.
We can ping the robot from the programming laptop so our addresses are correct. The network interface indicators on the laptop and the cRIO are furiously flashing away which tells me that traffic is going over the network. We are directly wired to the cRIO from the laptop with no switches or other devices. We have tried different cables also.
Its like the network comms are good but for some reason the cRIO refuses to respond to the deployment commands.
The programmers tell me that they built and deployed code to the cRIO firmware last night which is when this problem started. They also tell me that if they re-image the cRIO then they can deploy the code successfully but only once. I had them re-image the cRIO but with the “run apps” switch turned off. After that we’ve been able to deploy the code with Run button occasionally but not consistently. It’s like the cRIO is too busy to respond to code deployment for some reason.
Like I said earlier this problem seems to reoccur every year (we’re using a new cRIO this year so it’s not directly related to the cRIO itself). Its driving me nuts because we waste so much time waiting on failed deployments.
Does anybody have any insights into what might be going on?

The known issues list explains that his is caused by the current version of the SmartDashboard implementation on the robot. A patch is expected to be released early next week, and there is a simple workaround which is to close the dashboard application and any other SmartDashboard clients you may be running such as the Java SmartDashboard or RoboRealm.

The issue occurs when the code is deployed as a startup app, and you then attempt to abort it and kick it out, typically to run something else. The session handler for SmartDashboard refuses to quit and the RT system puts up the Waiting … dialog.

Greg McKaskle

Hi Greg and Alan, have a deploying question for you guys. I am a CLD working with a team who is trying out labview for the first time this year (they have used C++ previously). I’m not sure if we are using the proper deploying method for our development. What is the normal procedure, should we just “Run” robot_main, or do we need to build and deploy the entire project everytime.

If we just use the “Run” method, does Labview only recompile and deploy the changes, or is still deploying the entire project? The issue we are having (aside from this waiting for cRIO bug) is that its seems to take a long time every time we press run (or deploy), it takes a good 5-10 minutes saying something like it is “preparing” the files required. This really breaks down the development cycle if it takes so long between builds? Are we doing something wrong? Its much slower than when I’ve done similar things with rCRIO or PXI systems at work?

Shahrukh Alavi

The first time you Run Robot Main, the computer does a bunch of checking and sends every vi to the cRIO to be run in memory. This takes a long time. As long as you don’t shut off the robot or otherwise disconnect LabVIEW from it, the next time you Run Robot Main it only sends a vi if it has changed. This takes much, much less time.

If it’s taking a long time to Run when you do it again, you’re probably doing something to lose the LabVIEW connection. You should just click the big Finish button on the Robot Main vi when you want to start making changes to the code. The development cycle is quick, once you’ve sat through getting it started the first time.

Thanks, I think our problem was that we were “deploying” the project and then resetting the robot to get the new code to run at startup. I suppose this “breaks” the connection you were referring to, and we have to start over the next time.

This is what the other programmer used. The only difference is that he changed the motors from the Jaguar used in the example, to the Victor. Our motor controllers are Victor 888, and I’m not positive exactly how he changed it. Otherwise, as far as I know, he followed the tutorial step-by-step.

Is there any hack-y work around to get the thing to run, even with the current glitched “SmartDashboard” (what program is this? Is it on the Netbook, the robot, or what? Not sure if I’ve seen anything like this.)

And also, referring to “If by some chance you didn’t select the checkbox to “always run deployed code” when you reimaged the cRIO, code that you Deploy won’t actually be run when the cRIO starts up. To ensure that your code gets run on startup, use the “Run as startup” command instead of the “Deploy” command.”
I indeed did not select the checkbox to always run eployed code. Should I go back and do that? Or is that inconsequential to my current issue?

Finally, my problem seems to be the exact same as BitTwiddler’s (save the fact that I’ve yet to get any movement- not sure if he was able to achieve that).

There are two things wrong with following that tutorial. First, it carefully tells you to enter the cRIO’s IP address as when creating the project, and even repeats it when telling you to make a new VI to play with. That’s wrong – the middle two octets shouldn’t be zeros. They need to match your team number. In your case, it should be instead. That error would keep you from being able to connect to the cRIO in order to send it a program.

Second, it’s just a quick example of using the motor functions. It won’t work in a competition environment. You need to use the framework (which is there but ignored by the tutorial) in order to create a program that will let you control the robot properly.

Is there any hack-y work around to get the thing to run, even with the current glitched “SmartDashboard” (what program is this? Is it on the Netbook, the robot, or what? Not sure if I’ve seen anything like this.)

SmartDashboard is a data-sharing scheme built on top of the Network Tables communication protocol. When you run a robot program on the cRIO, it starts a server process. Client programs on other computers connect to it in order to send and receive shared data. The stuff on the Classmate screen is actually two programs; the Driver Station program is the bottom third, and the Dashboard is the top part with the camera view window and various joystick and motor status indicators. The Dashboard program sends and receives SmartDashboard data to and from the robot program. There’s a bug right now that keeps the robot from accepting a new program if the Dashboard is running, so you will need to shut down the Dashboard first (the simplest way is to temporarily select “remote dashboard” on the Driver Station’s Configuration tab).

And also, referring to “If by some chance you didn’t select the checkbox to “always run deployed code” when you reimaged the cRIO, code that you Deploy won’t actually be run when the cRIO starts up. To ensure that your code gets run on startup, use the “Run as startup” command instead of the “Deploy” command.”
I indeed did not select the checkbox to always run eployed code. Should I go back and do that? Or is that inconsequential to my current issue?

It shouldn’t matter, as long as you always follow “Build” by “Run as startup”. There’s never really a reason to use “Deploy” that I can think of. But if you want to make things a teeny bit more error-proof, you should take the few minutes necessary to set that checkbox.

Finally, my problem seems to be the exact same as BitTwiddler’s (save the fact that I’ve yet to get any movement- not sure if he was able to achieve that).

Your problem is probably that you’re following a tutorial example that isn’t strictly relevant to the task of programming a competition-ready robot. Try this documentation instead.

Also look at the Tutorials that were included when you installed LabVIEW. On the “FRC 2013 Getting Started” window that appears when you launch LabVIEW, choose the Tutorials tab at the left side. You’ll want to read Tutorials 4 and 5.

The IP target for the robot is correct, I changed the imaging to “run at startup”, Remote Dashboard was selected, and we restarted the entire coding project using what we the links you provided said to use. We also put in a test Jaguar and our regular Victor 888 motor, and neither worked. I guess we’ll have to wait until after the update to see if we can get it running, because I’m honestly out of ideas entirely (save for going back to Java & Netbeans, perhaps).

The update only fixes what is broken.

Please describe what you are doing, what works, and what doesn’t.

Greg McKaskle

All of the information that I have for our robot.

Electrical: Standard battery, Power Distribution Board, circuit breakers, wires to the Victor 888 & to the Jaguar. Fan wires on Victor 888 are wired and the fan runs when power is connected.
cRIO is hooked up, all lights are lit and communication is constant (able to ping, ect.)
Digital Sidecar appears to be hooked up, have yet to go over it with a multimeter as we did with the motors, but it is hooked up exactly as the guides online showed.
Orange “safety light” is not lit at any time
Wifi is placed and powered, but not currently used.
The motor controllers connect to two large motors below our electrical panel.

cRIO Imaged with our team number (, for LabVIEW Software, with “Run at startup” selected. None of the toggle switches are on. It is also not in safe mode.

DriverStation shows green lights for communication, joysticks (we’ve tested atonimously and with joysticks), and robot code. Under “setup”, team number is set as 4701, and Remote Dashboard light is perpetually lit. Dashboard IP is

The LabVIEW project’s name is “AlanAndersonGuideProject-temp3.lvproj” (a documentation method, and it’s our third attempt. Don’t ask, this was made by a frustrated coder.)
Under items:
My Computer
-Sim Support Files (have not touched any of these subsets, so I’ll leave it as this)
-Robot Simulation Readme.html (not using the simulation at the moment)
-Dependencies (untouched)
-Build Specifications (untouched)

RT CompactRIO Target (
-Team Code (Inside is “Begin, Autonomous Independent, Teleop, Test, Disabled, Vision Processing, Periodic Tasks, Robot Global Data, and Finish”.vi) (all of these have been untouched)
-Support Code (Inside is Elapsed Times.vi)(untouched)

  • Robot Main.vi (untouched)
    -Simple Motor Control.vi
    This code has the following:


[Stop Button]
<up and down arrows> [0] (when running our code, we changed this value from 0 to 1 with no effect.)

Starting from the bottom left and moving up the wire (which I’m informed is actually a while loop?)-
an *, with nothing connected to it.
A green/brown wire, connected to [watchdog], which is set to OPEN, which reaches across to [watchdog] SET ENABLE, then to [watchdog]CLOSE.
[watchdog]SET ENABLE has a pure green line to the left of it, leading to an [f] which changed to [T] when I clicked on it (true/false?)
a pink wire, which connects all three [watchdog]s in the order I listed.

On the left of the “while loop” is something that says [DrwStn] Start COM. It’s not connected tot eh while loop. On the same level as it, to the right, is a watch symbol with “10” connected to it. It is also not connected to the loop. Then a [stop] box, with a green wiring connecting it to the right side of the while loop. On this green line, there is a stop sign connected. On the right, connected directly where the green line and while loop meet, there is [DrwStn] STOP comm (way to be consistent with capitalization, lol)

Back on the left side of the while loop, moving up is a brown wire connected to the left to [Motor] Open Jaguar (Jaguar), which has 2 blue wires readying “Digital Module 1” and “PWM 1” (it is connected to slot 1 on our Digital Sidecar). It also has a pink wire connected it to it, linking it to the while loop. The pink and brown wires go to [Motor] Set Output in the middle of the while loop, which also has Output[DBL] 1.23 connected to it. On the right of [Motor] Set Output is the pink and brown wire connected it to [Motor] Close, which is also on the while loop.

Finally, at the top of the while loop, on the left is a red wire connecting to [Joystick] Open, which has a blue wire leading to the left which goes to USB 1. This red wire connects to [Joystick] Get Axis, and this attatched to a blue wire which leads to Axis 1. Back at [Joystick] Get Axis, there is a red wire which leads to [Joystick] Close.

This is the code we’ve been trying to run on the robot (with the only changing variables being the Jaguar to a Victor, and the changing of PWM slots.)


-Dependencies (untouched)
-Build Specifications (inside is FRC Robot Boot-up Deployment)

Some possible idea’s I’ve developed: Digital Sidecar? Is it working right, and how do I test this?*

It sounds like you properly created a 2013 competition robot project, but then you just copied in that example instead of using the programming framework. Remove the Simple Motor Control.vi from your project and follow the tutorial instructions included in LabVIEW. Until you start doing fancy stuff, all your robot programming will be in the Team Code VIs.

You say the orange BFL (Big Flashy Light) remains unlit. Does the green LFL (Little Flashy Light) on the Digital Sidecar next to its connector also remain unlit? What about the three green power LEDs on the Digital Sidecar? What size circuit breaker is feeding the Digital Sidecar power input?

Good job describing things. This allowed for us to better troubleshoot. Hopefully Alan’s suggestion works for you. If not, describe what you want it to do and what seems to fail.

Greg McKaskle