Intermittent CTRE Configuration Errors

Robot has 8 Falcons and 6 SparkMax.
There are no CAN ID conflicts.
Every call to a CTRE VI in Begin is chained via the Error Wires. So there are no CTRE vi’s running in parallel in Begin
Same for the Sparks but the CTRE section is not chained to the Spark Configuration section.

When running code out to the Rio interactively we will quite often get this error in the driver station…
ERROR -200 CTR: No new response to update signal Talon FX 11 Config_kP

Now that is just an example. The error could be for a different Falcon with different CAN.
The error could be for a different configuration parameter.
For example I stopped this code because of the error and immediately re-ran it and got this error…
ERROR -200 CTR: No new response to update signal Talon FX 7 Config_kF

When the error occurs it effects all subsequent Falcons in the chain so effectively the robot won’t run. Many times it will take 7 or 8 runs before I get an error free run.

Sometimes bouncing the power on the robot helps. Sometimes replacing the battery helps.
But this is all anecdotal, I can’t find any real rhyme or reason.
Sometimes I’ll go 20 or 30 runs with no errors then the errors come and I’ll seem to never get back to an error free run.

Of course I’m running all the latest everything.

Phoenix Tuner seems to be able to see everything on the Bus at all times.
I’ve never run into an error running Tuner to run a motor or do ad-hoc configuration for testing.

Anyone else seen this before?

Sorry if these are obvious questions.
What is your CAN utilization (Driver Station power tab)?
Have you reduced the frequency of the CAN status packets?

How often are you setting the PIDF constants. Based on the error message I’m guessing very often. You should only set them when they change to reduce CAN utilization.

Nope, good questions.
45-60% CAN Utilization on the DS. Sometimes I see a 100% spike for a “millisecond”.
But, this prompted me to do look at the logs and I do see spikes at 100%.
Not sure what to do other than guess at what controllers and what status frames need to be reduced and to what timing (50ms? 200ms? - what is good or bad?)
Yes, I reduced the Status rate on the 2 Falcons that are followers on the drive base.
Wasn’t sure if or what I could reduce on the others.
2 Falcons are Masters on the drive base but we drive using standard ArcadeDrive.vi
2 Falcons control the shooter and we control them using Velocity PID running on the Falcon.
2 Falcons control our climbing arms and we control them using Positional PID running on the Falcons (Motion Magic). But those really aren’t used until we climb.

Of the six sparks only 3 are used in positional control the other 3 are just percentages.
If reduced the status frames on all those 3 (reduced those to 500ms on all the frame groups).

I assume I need to do more, but what? It’s strange to me that I can’t find too much discussion on best practices on reducing unnecessary CAN status messages.

I set PIDF constants once. During configuration of the controllers in Begin.vi

I should add this seems to only happen when running the code interactively.
If I deploy to the Rio, I don’t see this.
Now, I’m not sure about CAN utilization on the deployed code so I’ll look at that later today to see if there is a difference.

You can try chaining the whole opening sequence in Begin, so each device finishes setting the PIDF settings before moving on to the next device.

Running with the front panels greatly slows down the code (with all the back-n-forth required for debugging and keeping the front panel indicators populated). Closing unnecessary front panels improves performance.

There is a document on suggested CTRE message frequencies. I have to find it. In particular, reduce the frequency of any messages you aren’t actually using to > 100ms.
image

Here it is:

That’s great information. But those show the default update rates.
So if I’m not using PID1 should I just turn it off or set it to some huge number like 50000?

These messages are just numbers reported to the Rio that I can look at by using various GET vi’s. Right?
So if I’m not using the information in my program couldn’t I turn almost all of them to huge numbers?

Like even Status_1 which defaults to 10ms. I’m not looking at Applied motor output, faults or limit switch information anywhere in my program. So couldn’t I set that to 50000?

Now, If I DID want to see that information I’d have to remember to switch it back to 10ms or something.

Just looking for potential pitfalls or unintended consequences if turning the update rates real high.

I know that the follower motors need the updates from the masters but what status frame is that?

I know if I was doing PID1 calculation to keep to controllers in sync I’d need to keep those status frames rolling.

But are there any other “gotchas”?

Yes, for the most part if you aren’t using the info and a follower or other device also doesn’t need it then a high number is fine.

You do want fault status and motor output (status 1) to be frequent. Motor output will be used by the followers, and without fault status you won’t know when a future problem crops up (no message on the Driver Station or log).

I’d suggest setting all those changes in Begin, so you always know where to find them in the future if you decide you do want to Get any of those values. For instance, debugging you might temporarily want to turn some of them back on.

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