Trouble deploying simple Talon SRX and Spark Max code

Just use the error output to force each Open to occur one at a time like this.
Chain Opens

I’ll see if I can replicate what you guys are seeing, so I can take a closer look.
Are all these with roboRIO 1.0’s?

Rio 1.0 in our case. (Confirmed. Our current code is not chained)

I wouldn’t call it a recommendation to normally chain those. Normally, we wouldn’t have to chain those operations.
It’s a diagnostic to see if opening them one at a time affects the problems you are seeing.

The results just lead us to another step in the debugging.

I’m digging through my supply of motor controllers to hook up a testbed…

We are using a RIO 2.0. I’ll try the chaining tonight to see what that does. Thanks for the suggestion Mark.

I’m both worried and relieved that others are seeing the same thing. It likely means I’m not going insane (relief), but also means the problem might not be an easy fix.

Since it’s easy to replicate it’ll be easy to find and probably easy to fix.

I love your optimism Mark!

It’s a sickness I have :slight_smile:

Hey all,

We got an initial report of behavior like this last week and we’ve been working with some NI folks to figure out the issue.

We’re still troubleshooting to determine the root cause and what changed between beta and kickoff (whether in Phoenix or LabVIEW) to cause the issue, however the workaround is to chain all Phoenix Open VI error signals to force sequential initialization, as Mark referenced in an earlier post.

Note that only the Open VIs need to be chained, all other VIs can be used as normal.

We’ll have some additions to our documentation up today that highlights the necessary workaround.

Thank you Jacob. Now I’m excited to get to practice tonight so I can try it!

Lucky guess.
Chain Opens 2

We are seeing the LabVIEW disconnect thing somethings, however changing the target to use the USB address seemed to help this.

We are also seeing a similar but different problem when using talon srx.

  1. Sometimes it takes what seems like a long time for the robot code to restart after new code is loaded. (Same thing if you restart robot code, or reboot roborio.)
  2. Sometimes the talon SRX don’t drive. We are using 2 talon per side (one follows the other). These are connected into the standard existing 2 motor. Then using the standard update 2 motor VI to set output (We haven’t tried strictly using the CTRE provided code yet).
  3. Power cycling the roborio (not just rebooting), without deploying new code, seems to correct this.

Here are screenshots.



Network table values update, but motors don’t move. Motor reference appears to be good.

I have also had the talons not moving at times with power cycling help. We’ll see if that continues after implementing this work around.

Just implemented the work around and things seem to be working well now. Thanks all. Particularly Mark. If we end up at Championship together I’ll buy you a beer (or beverage of your choice)!

A beer would be fine :slight_smile:

Have you tried clearing the compiled object cache and than doing ctrl + shift + run button? This worked for a different team with a similer issue

The post in question

Chiming in with a “Us Also”.

RoboRio 1 - We have formatted it several times trying to fix our strange behavior.
Programming laptop was completely wiped pre-season with fresh install of Windows and so it got an original install of Labview FRC 2022.
Always after formatting we use the Tuner to install CTRE libraries.

Our current robot has a 2 CTRE Falcons and 2 SparkMax controllers.

What is happening to us is that running the code out for testing and using Robot is troublesome at best. I’ve had 45 minutes where I could not run code to the RoboRio.

But when it starts working (magically) it works well afterwards.

Next, which is worse, is Building then doing “Run At Startup”. The compiled code runs fine until we power cycle the robot. After the robot comes back up and everything is green, any CTRE controller will not respond to CAN signals. SparkMax’s run fine. Driver station doesn’t show any unusual CAN activity percentage.

If we connect the robot to the programming laptop using USB, Tuner sees all the controllers but cannot control them. While doing this checking the robot is Teleop Enabled. If we check the status of the controller using self-test the top of the status says the Falcon controller is not enabled.

We have a second test platform robot with 2 Talon SRX and we get the same behavior with those and the most simple of code.

At the end of the day today we could get the test platform robot to run with built code by restarting the robot code (not rebooting the rio) via drivers station one or two times, then the CTRE controllers would respond.

On Tuesday I will implement this sequential opening workaround and see if that fixes the issue.

To add on to this “Us Also” from 3572:
When the issue occurs, Anything CTRE will show in the tuner, However, Any attempts to control via LabView or Tuner while enabled don’t work at all. (SRX and FXes stay in their alternating orange state despite FRC DS being enabled and RIO being loaded with working robot code.) I have also noticed while booting up or while loading code to the robot, SRX and FX motors blink wonky (Kinda looks like it’s oscillating between alternating orange and alternating red for a brief moment, multiple times during). If the wonky blink happens, Nothing works. If it doesn’t blink wonky, everything works.
I will also point out our issues is also occurring regardless of network connection type to the robot, and while disconnected from all other networks.

This also my experience. The workaround (cascading open VIs) did the trick. So far, no issues. Thanks

Note that CTRE released a fix with the latest (Feb 4) Phoenix Framework:
Blog - 2022 FRC and Product Update - CTR Electronics
Software - Software