Trouble running program to roboRio

[AfterTen]

Our roboRIO is giving us fits.

I seem to be only able to download programs to it the very first time I connect to it from my Windows 10 PC and even then it is intermittent.

What happens when I choose "Run" from my "Robot Main.vi" is I get they typical "roboRIO already running a real-time program, do you want to replace..." blah, blah.

The it doesn't to the screen where it starts to scroll all the VIs it is downloading.

It goes through specifically 5 VIs before it starts with "Waiting for Target To Connect". 20% of the time, after a pause, the program downloads to completion. And, if it does then I will not have any issues running programs.

80% of the time I get two more "Waiting for Target" messages then nothing.

If I do get lucky and it does download the program then I will not have any more issues until I disconnect from the RIO then I will not be able to connect back.

During this time when I cannot download the program, the web interface in IE works file. The driver station shows green light communications.

Here are the versions the roboRIO show...

DS: 18.0.1

RIO: FRC_roboRIO_2018_v17

Lib: 2018 LabVIEW Update 2018.1.0

PDP: 1.40

Talon SRX: 3.3

We have re-imaged several time. After the reimage it works fine but quickly degrades back to the situation I've described.

Any advice?

UPDATE: We reimaged our RIO to FRC_roboRIO_2018_v16 and cannot get the problem to occur. The RIO functions normally so far.

[MarkBalla]

It is possible that your program on the roboRIO is running the CPU near 100% and will usually make communications a lower priority than running code.

While the roboRIO is running the previously deployed code look at the driver station and click on the charts button on the right hand side. 

The red line represents the % CPU usage if it is close to the 100% then you code is using too much band with. The max you want to shoot for is 80%.

The web interface allows you to disable a startup program that is causing problems by checking the "Disable RT Startup App" in the Home tab.

After you click the box click save and reboot the RoboRIO.

The startup app will be disabled and your CPU should be much lower.

As to why the program is taking up so much CPU the number 1 cause is no waits in your while loops.

Please post if you have further questions.

[AfterTen]

I will try that and report back the results later this evening.

If this were the issue, can you think of a reason v16 would not exhibit this same behavior?

[BoKnows]

That's likely a red herring.

The changes made in the mid-season update affect a small bug in the driver station and console output for Java and C++ teams.  

It's more likely something changed as the team progressed through building code for the season and one of those changes happened around the same time.  You can always test this by installing the original 2018 Update Suite.  If that eliminates the issue, I'd be very interested to know this.  

As a heads up, the update will say it's mandatory on the LabVIEW Welcome Screen.  But, it's an optional update.  There just isn't a mechanism to show that.  It will treat all updates as mandatory.

[nestor-sg]

It's more likely something changed as the team progressed through building code for the season and one of those changes happened around the same time.  You can always test this by installing the original 2018 Update Suite.  If that eliminates the issue, I'd be very interested to know this.  

---

BoKnows, where can I find the original 2018 Update Suite image ZIP file for the roboRIO?

Our team is having the exact same problem, and we've been troubleshooting this issue extensively. Is as if some corrupted file is being installed by the deploy. To add info, everything worked fine while running Robot Main VI from the project, it was until we built the EXE and set it to run as startup app, that when it rebooted, we can see (CPU%) that the app is running but the DS says No Robot Code. After this, if we want to re-run from the project we are unable. We have to either reimage or work through the kill startup app and use an older snapshot of our code to get back to work. Tomorrow I will be trying to connect to the remote RT application in debug mode, to see if there is any clue as to where it is failing, seems like some function is running fine when run from the project, but failing when run in an EXE.

[nestor-sg]

A quick update on our progress this weekend. I went in and had a chance to start cleaning up the team's code. I think our behaviour was caused by what was already explained in this thread earlier.

The team's roboRIO CPU usage was running almost at capacity (~90+%) this according to the Log File Viewer. So, I looked at the team's code and scouted for places we could optimise/clean the code, the team's code had 2 arcade drives running, one for the drive, another for the climber winch, we eliminated the second arcade drive and replaced it with just a regular motor control (PWM) and I also passed them a few suggestions with regards to optimising redundant operations, things that do not be to called at every Teleop VI cycle, disabling other things when not needed (e.g. Vision), etc.

Anyway, our idle (disabled) robot is now pulling ~30% usage... and when in Teleop is pulling 50-65% usage. We no longer see the crashing issue. I think the earlier recommendation of keeping CPU usage under the 80% would be a good guideline to follow.

I hope those suggestions help the other teams having issues. Cheers!

[AfterTen]

Thanks for the input.

I'm going over the code right now to see what could be causing an issue.

We don't look like we over 80% but might be strattleing that line. I'll look in the log file for more definitive numbers.

The vision thing has me curious though. We are not using vision this year but to have a camera attached and feeding that to the drivers station.

We keep that default "Vision Enabled" control in the "False" position, is that enough or should be be stripping out the vision processing code that is included in the default robot project, you think?

[nestor-sg]

It doesn't hurt to disable it for now.... but basically you first want to get the roboRIO to a working state.... and that means getting rid of the existing startup executable which is causing you issues.

Go through the web interface process to disable it (explained earlier in this thread), restart the roboRIO and then download a minimal project for testing.

However, in our case, I actually decided to reimage the roboRIO and reinstall the CTRE phoenix utilities, it takes me 10 minutes and I had a clean roboRIO to start with. Then I started downloading a stripped-down version of our code (e.g. Vision, Periodic Tasks are disabled by a Disable Structure around them) and had a smaller version of our Teleop. Then I confirmed I could download and run from project, and also build a working startup EXE... and from there, I started adding small enhancements, run from project, run as a startup EXE, check CPU usage, etc.... one step at a time. I was optimising the team's code while doing this, and after a while we now have all of our code running fine, no more problems. While doing the optimisations I was able to profile the performance improvement in some cases (like the arcade drive I explained in my last post).

I hope this is a similar case to yours, good luck!

[nestor-sg]

It turns out that our issue is caused by this:

https://github.com/CrossTheRoadElec/Phoenix-Documentation/blob/master/LabVIEW%20Deploy%20Issue.md

Our team (4343) has been seeing the exact same issues... and just this last weekend we updated to the newer libraries as specified there. Too early to say that actually fixed it... but we made changes in the code in which we serialize/sequence CTRE calls and we stop seeing the issue at least in the last couple of days.

If you are, like us, using a lot of CAN Talon SRX or making CTRE calls in parallel, you might want to follow that link's suggestion and update to the latest Phoenix framework (5.3.1.0) and the Talon firmware (3.8).

Cheers!