Is there a way to make it so that our team doesn’t have to disable RT startup app in order to deploy code? It is very time consuming in the pits when we have to modify code, jack into the roboRIO, change startup settings, test the code and then build down and jack into the RIO again.
This is usually because your CPU usage on the RIO is so high that the RIO doesn’t set aside enough for the ethernet and to stop the code from running.
Check your CPU usage when your robot is sitting in disabled. Is it above 90%?
First get some help in streamlining your code.
You could add an abort function to your code where your code exits when a special combination of buttons are held down. But it’d benefit you in other ways to improve your code.
Mark - I had never even thought about adding a ‘stop running’ button combination. That’s a really good idea. How would you command the code to stop?
An annoyance we’ve had lately is that the code occasionally fails to deploy with an error. After that, there is a non-stop string of errors because (I suspect) the first thing that happens on a new code deploy is that the CTRE libraries are deleted in preparation for placing the new ones. The CPU goes to 100%, sometimes taking as many as 3 or 4 deploys before it goes through all the way and replaces the libraries again.
I’ve actually considered writing a psftp script to place the libraries just to fix that issue.
Depends on the language, but in LabVIEW for instance, just trigger a call to Finish.vi
For just that issue, I wonder if you could store a backup of the libraries on the rio.
Then trigger a process on the rio to reinstall them from the local repository-no ftp required.
We haven’t checked the CPU usage, thank you for the suggestion though
Thanks for all the suggestions
So we ran Auto and Teleop and the CPU usage was around 60 percent. Is that normal?
Also, at our recent competition, the first time joystick initiation was spammed and auto didn’t work at all as well as teleop and the RSL blinked briefly but was solid for the rest of the time, the second time auto and teleop didn’t work at all but robot code, comms and joysticks were all green, and the RSL was solid the entire time
60 is fine. What problem do you have deploying? Why are you disabling rt startup?
We have to disable RT startup in order to deploy code to the roboRIO . That was a fix we found on Chief Delphi.
What error do you get when you don’t turn off rt startup?
The robot code couldn’t deploy, the error would read something along the lines of “failed to connect to Target”–But now everything has somehow resolved and running code is fine
We shall continue testing however to see if the error comes up again
We’ve been experiencing similar hinkiness this year too. Usually when we attempt to Run as Startup (following a successful Build) the existing RT will take about 20 seconds to interrupt, a file transfer will begin, then comms will drop (tethered) and we will “Fail(ed) to Connect to Target” until we reboot everything. We eventually just started FTPing the compiled .exe instead and things were much more consistent. We’d previously lose the CTRE library as well. Definitely didn’t behave as advertised.
Do you guys use LabVIEW? that has been jank as well because earlier this year there was a bug where you literally couldn’t create subsystems because of a broken wire in the source code. Also losing the CTRE library is definitely unusual
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.