After working through many frustrating errors, our robot finally has code. said code at first only moved one wheel, and now does nothing, with no programing or wiring errors as far as anyone can tell. we then discovered that after building the code, labview directs us to a new folder, but this folder does not contain anything deploy-able to the robot. please help a clueless first year programer out.
The directory should contain a folder called “c” and a .bin called depinstr.bin, neither of which you can do very much with. Go into your project explorer > RT CompactRIO Target (10.te.am.2)>Bulid Specifications>FRC Robot Boot-up Deployment. Right Click to build, and then “Run as Start up”. If you have done all of these things, check your driver station error log.
Tell us the steps you’ve taken.
For instance, did you:[ol]
[li]Create a default robot project[/li][li]Put your robot up on blocks and power it up[/li][li]Downloaded the default program to your robot:[ul][/li][li]Right-click on Build Specifications -> FRC Robot Boot-up Deployment and choose Build[/li][li]Right-click again on Build Specifications -> FRC Robot Boot-up Deployment and choose Run as startup[/ul] [/li][li]Plug one joystick into your PC[/li][li]Startup the Driver Station application and see if the Communication and Robot Code lights turn green[/li][li]Enable your robot[/li][*]Test the joystick[/ol]
ill give it a try and see what happens. thanks for the help
those are pretty much the exact steps i took, except bi modified the code to a tank drive setup with two joysticks and to run on victors instead of jaguar. in the newest attempt, i am also getting conflict message saying the code has not been built, when i just finished doing that.
Try a brand new default project first without trying to modify it in any way.
That’ll tell you if your basic setup is alright.
You may have a broken autonomous. Because the linkage between the RobotMain and Autonomous is a runtime based call, the breakage isn’t reported until you build the app. The same could be true of Test.
Open the Autonomous and Test VI and inspect the run arrows. If broken, click it and see if you can fix it.
Then Build and Run as Startup.
Greg McKaskle
no part of the project has a broken run arrow (though their could be other problems) and we can now consistently deploy code, but the controls still will not work, even though the drivers station detects them
After a long day of playing around with labview and some help for some alumni, they finally got the code to deploy, and the robot to move. From there Frew added in all the other functions of the robot and problems happened again, the code deploys seems to turn on for a second then nothing, A loop error comes up on the drivers station. They played around looking at other code online but can’t seem to get it to work, I really don’t know much on programming, But said I would post for Drew to help out. Everything worked until we tried adding the relays.
Here is the code.
Begin.vi (40 KB)
Teleop.vi (39.6 KB)
Finish.vi (25.4 KB)
Begin.vi (40 KB)
Teleop.vi (39.6 KB)
Finish.vi (25.4 KB)
I don’t completely follow what errors are occurring, but are you certain that you aren’t suffering from the “Waiting for …” issue that was documented in the known issues list? The symptom is that once you have deployed code to the cRIO and it is running as a startup application, it doesn’t abort properly so that new code can begin running.
A LabVIEW update 5.1 was released primarily to fix this issue. The workaround documented on the known issues list involved aborting the dashboard before starting to download new code. This allowed for the deployed application to abort cleanly.
Greg McKaskle
The words “loop error” seem to be referring to a message telling you the loop containing the motor drive commands is running too slow. Is that correct?
The code looks okay. I don’t see any problems in Teleop that would make it run slowly. Is there anything in Periodic Tasks? Perhaps something in there is using up all the cRIO’s CPU cycles.
Yes that is what I meant. I dont believe we put anything into that, here is the file, I also have gone through and reinstalled all the required updates. Here is the link, thanks for the help.
Periodic Tasks.vi (21.1 KB)
Periodic Tasks.vi (21.1 KB)
I don’t see anything in the Periodic Tasks that should cause it to run slowly or consume CPU. There is one piece of code with the encoder that isn’t in a loop, so it will only run one time.
If you have the newer driver station, it will show you CPU usage for different modes of operation. Does it help you understand what the robot is doing? Is the disabled robot CPU high? Is it just teleop? Is it auto too?
Greg McKaskle
The “loop running too slowly” error can also be caused by the Driver Station computer being overburdened. Are you running anything CPU-intensive on it?
we are no longer getting the slow loop error, but there are a few new problems.
The compressor does not stop at 120 psi.
The shooter motor does not respond to joystick 3 (or any other control).
The strangest part is that all the buttons i have set to control a piston move the drive train instead.
here are all the vis I changed. if you need to see any others, ill post them as well.
Begin2.vi (43 KB)
Teleop2.vi (37.5 KB)
Periodic Tasks2.vi (23.4 KB)
Finish2.vi (27.5 KB)
Begin2.vi (43 KB)
Teleop2.vi (37.5 KB)
Periodic Tasks2.vi (23.4 KB)
Finish2.vi (27.5 KB)
The drive train also no longer whines or “twitches”
The compressor code looks right. Do you have the pressure switch wired across the SIG and (-) pins of DIO1? Can you verify that the switch opens when the pressure reaches 120 PSI? Is there perhaps a short circuit across the connections, such as a bit of metal in the DIO pins or a stray strand of wire on the switch terminals?
The shooter motor does not respond to joystick 3 (or any other control).
The strangest part is that all the buttons i have set to control a piston move the drive train instead.
But your program doesn’t have anything that would let the drive motors react to any buttons. Are you perhaps moving the joystick a little when trying to press a button? Check the Setup tab on the Driver Station and make sure the three joysticks are in the order you think they are. Pressing any button on a joystick will make its name change from green to blue in the list, and add asterisks. You can drag the joystick names around to put them in the order you want them to be in.
The reason the controls were going crazy was that the sidecar was ony drawing power from the cRIO and not the battery. we fixed this problem and a few other minor issues, and everything seems to be running smoothly. thanks to everyone for all the help!