Unable to connect to Real Time Target

[gamegeek1995]

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., 10.47.01.02 for the robot, 10.47.01.05 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?

[rsisk]

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

[Alan Anderson]

Originally Posted by gamegeek1995

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

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 10.47.1.2 might work where 10.47.01.02 doesn't.

[gamegeek1995]

I went through http://www.usfirst.org/sites/default...trolSystem.pdf

for the second time, this time configuring everything for 10.47.1.2. 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

[Greg McKaskle]

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

[Alan Anderson]

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?

[61kodkir]

Originally Posted by Alan Anderson

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

[Alan Anderson]

Originally Posted by 61kodkir

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.

[BitTwiddler]

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?

[Greg McKaskle]

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

[shahrukh]

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?

Thanks,
Shahrukh Alavi

[Alan Anderson]

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.

[shahrukh]

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.

[gamegeek1995]

Originally Posted by Alan Anderson

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.

http://www.applepirobotics.org/wp-co...loads/2012/02/[FRC%202012]%20Basic%20Motor%20Control%20Tutorial.pdf

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).

[Alan Anderson]

Originally Posted by gamegeek1995

http://www.applepirobotics.org/wp-co...l Tutorial.pdf

There are two things wrong with following that tutorial. First, it carefully tells you to enter the cRIO's IP address as 10.0.0.2 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 10.47.1.2 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.