Unable to connect to Real Time Target

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

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

[gamegeek1995]

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

[Greg McKaskle]

The update only fixes what is broken.

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

Greg McKaskle

[gamegeek1995]

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.

Software:
cRIO Imaged with our team number (10.47.1.2), 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 10.47.1.6

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 (10.47.1.2)
-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:

-BEGIN BLOCK OF CODE

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

BLOCK DIAGRAM
Starting from the bottom left and moving up the wire (which I'm informed is actually a while loop?)-
an [i], 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.)

-END BLOCK OF CODE


-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?

[Alan Anderson]

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?

[Greg McKaskle]

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

[gamegeek1995]

Originally Posted by Alan Anderson

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?

Not sure what the LFL is (and I'd honestly be surprised if the 'F' stands for flashing )- I don't see any small green flashy lights. The three green power LEDs on the Digital Sidecar are lit though, and the 20amp Circuit breakers that came with our kit are installed above its WAGOs. We're about to go through the tutorials for LabVIEW and try to understand this infernal GUI language.

Question: Is there a way to check if our issue is the ribbon cable?
Edit: So, we didn't put the ribbon cable in a press. We just did that and will test our stuff again to see if it will work. I'm glad I randomly decided to browse the forums and find the Java post about that being their issue. Now I feel like I'm the dumbest human being in the world. I'll tell you if it works.
Edit2: UPON CONNECTING THE NEW RIBBON CABLES, THE BIG ******* ORANGE LIGHT BEGINS TO BLINK. To the Cliffs of Dover!
EDIT3: AFTER RUNNING ROBOTMAIN.VI, IN THE PROGRAM I DESCRIBED EARLIER (NO CHANGES), THE ROBOT MOVESSSS AND IT MOVESSS CORRECTLYYYYYYYYYYYY YESSSSSSSS VICTORRYYYYYYYYYYYYYYYY!!!!11!!111!!1!!

[gamegeek1995]

Got the wireless router config'd and it runs autonimously. Thanks for the help guys

[Greg McKaskle]

I found the known issues list here ... http://wpilib.screenstepslive.com/s/...software-notes

Greg McKaskle