2020 Imaging/flashing (RoboRio) and Pheonix Tuner Problems

Last night while another programmer and I where trying to reformat RoboRio’s on our robots, If we reformat the robot(2020_Season_V10) and tried to re install the firmware after it, it would give us an error for installing the firmware. We went through the list that the imaging tool gave us, disabling the firewall, running as admin,but turning to the robot to “Safe Mode” worked, but now when we attempt to change ID Numbers on our Talon SPX’s(CAN) using the Phoenix Tuner we were unable to connect to the RIO(VIA USB) it would say Unable to connect to “DEFAULT ADDRESS” GENERAL ERROR, the IP address was the default address and when I checked in the Imaging tool it was the same.

We where able to connect to the Phoenix Tuner before imaging and re-flashing the Rio but no CAN devices where showing, There was also a notice to deploy code to the robot if you where on the 2020 beta, I deployed a template subsystem because I was limited on time to check if it worked, but it did not. Should I deploy code that uses the Talon SRX.

1 Like

Two things to keep in mind here. 1: If no CAN devices are showing up on the Phoenix Tuner, then something is wrong with your CAN Bus. Check the wiring on each connection to ensure a complete circuit. 2: You need to deploy code that has the Phoenix Library in it. Also try connecting via other methods (ethernet, Wifi). Make sure you are connected on the driver station as well.

1 Like

When using Phoenix Tuner over USB I find it easier to just enter (the IP of the roboRIO) manually instead of trying to have the DNS thing resolve it correctly.

For info here: https://docs.wpilib.org/en/latest/docs/networking/networking-introduction/roborio-network-troubleshooting.html

Yeah my electrical lead Guarenteed me that it was wired correctly. But in all seriousness though we swapped the CAN Bus last night but the Phoenix tuner wouldn’t connect, so I will deploy code with the CTRE/Pheonix Librarys on it.

I understand the point of @Riley_Blair’s statement, but I also have struggled through the Phoenix/ Rio 2020 issue in the past 12 hrs. The fact that CAN devices don’t show does not 100% mean that the bus is wired wrong. If there is a connection issue, it might look like no CAN, but it’s really not communicating correctly with the Rio.
Our solution looked something like this:
We re-imaged the Rio, then in Phoenix ran the tool to install phoenix onto the rio, then all seemed well with the world. We were then able to see the devices and work with them. The student MIGHT have pushed some Code to the bot between running phoenix on the rio and the CAN devices showing up, but I couldn’t get a straight answer once it worked.

I have no idea what imaging in Safe mode might have done with this process as I have no experience working through that. Your other symptoms match perfectly with what we were seeing this morning though.

Make sure you not only deploy with the libraries loaded, but also make at least one call to one of the API methods of Phoenix. Creating an instance of a TalonSRX / FX in your template subsystem should be enough to do it. Also, if you didn’t know, Phoenix Tuner has a built in button now to deploy a robot program which does this for you automatically, which saves time before any code is actually written.

1 Like

We had the same problem. We deployed code (labview) but were not able to see any devices with Phoenix Tuner (CAN bus known good). Only after downloading code 3 or 4 times, uninstalling and reinstalling temporary Phoenix server, were we finally able to see CAN devices. There was no hardware change - just kept downloading and resetting roborio. NOTE: We were getting error messages in DS that libraries were missing (as identified in the CTRE troubleshooting directions). I do not know what finally fixed it but it did eventually work and seems reliable for now.

FYI there is new Tuner update (1.5.9) that we just posted

Although it sounds like the original issue was root-caused as a wiring problem.

Team 1164 here. Just wanted to chime in here as this tripped us up.

#2 listed by @Riley_Blair here is essential. You have to have some robot code that uses the Phoenix Library loaded on the RoboRIO in order to see CAN bus devices in the Phoenix Tuner.

They seem to have changed behavior from 2019. When you install the Phoenix daemon on the RoboRIO, it says (in part):
“Standalone Diagnostics Daemon only supported on 2019 RoboRIO images.
If you are using the 2020 FRC beta, run a robot program with Phoenix to use Tuner.”

If you don’t have robot code yet that uses the Phoenix library, you can push the button to deploy their “Temporary Diagnostic Server”. That server will take the place of your robot code, and should let you see your CAN bus devices. The Temporary Diagnostic Server doesn’t seem to survive RoboRIO reboots, however, so you’ll have to push the button again if you power cycle the RoboRIO… at least until you have some robot code deployed that uses the Phoenix library.

This is already explained in the documentation.

This is also explained in the actual tab in Tuner.

Or use the ‘Temporary Diagnostic Server’ - as you mentioned.
As I mentioned earlier, there were related fixes since Kickoff. So be sure to update if you plan on using the temp diag server. This is the relevant update below (or just use the latest release).

Relevant Update


That’s intentional. If you are using C++ or Java, it merely moves your app out of the way temporarily. A power cycle will restore your C++/Java app (if one exists). LabVIEW teams will have to re-Run-As-Startup, or press the LabVIEW button in Tuner.

This means you can use Tuner to rule out your FRC application by deploying the temp app and testing in Tuner. This also gives you the ability to switch between a C++/Java application and LabVIEW application in the RIO. Neither of these were design-goals, but merely a consequence of changes triggered by NI’s CAN bus improvements.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.