CTRE TalonSRX setStatusFramePeriod Question

[NewtonCrosby]

When we put our arm talon into MotionMagic control mode we are seeing the error message CAN Error 200, no status update signal received.
(I’m paraphrasing that error message as this was happening 12 hours ago and I forgot the paper where I wrote down notes)

Looking through the API, it would appear that the SetStatusFramePeriod() method is what we would need to update.

What I couldn’t find in the documentation is how often is too often with respect to the update frame. I see the Status 10 messages (for Motion Profile/Magic) says the update is > 100ms, which seems like that is the status message I need to increase.

Do I just choose a value and check the CAN utilization on the Rio to make sure it’s not too much, or is there a more calculated way to know what value to use?

[Joe_Ross]

The status frame should be handled automatically by the firmware and library. You shaoildnt have to change anything on your code. What firmware version and library version are you using? What is your CAN utilization?

[NewtonCrosby]

I don’t have the robot in front of me, but we updated them on Monday to the latest. I believe the version was 4.17, but I could be off on that one.

It’s only on the Talon for our Arm, the drivetrain and other mechanisms are fine…and it’s only when we put the controlmode to MotionMagic.

Our Github is public if you see us doing anything incorrectly please let me know. This is the first year we’ve ever tried motion profiling/magic so we’re sort of out in the weeds when it comes to troubleshooting.

[ozrien]

Next Steps

Full error

Error 200, no status update signal received . (I’m paraphrasing that error message as this was happening 12 hours ago

The full error is important, it will tell you which line of code is the problem.
Luckily your DS logs these messages, so go to the DS logviewer and get the the entire message, with the callstrack/trace.

That error suggests you get a configGet* or a configSet, and the Talon/Vic did not respond.

Get familiar with this log as you will need it during competition.

kTimeoutMs

Your kTimeoutMs appears to be ‘5’. I would dial that up until error goes away, only waiting 5ms for the response but not be sufficient. Remember this timeout expires when a Talon is missing on the bus, but typically the actual transaction is much faster. So this define can be quite large.

Also remember your configs* are done on boot up, and our configs are magically persistent. This means your kTimeout does not influence the runtime operation. Making this a low-risk code modification.

Makes sense?

[NewtonCrosby]

As you say that, I do remember now there was some appended text to the error that was related to closedLoopError.

If I’m understanding you correctly, it’s likely this method that is not getting the response:

public void move_MM(double targetPos) {

        armMotor.configAllowableClosedloopError(0, 10, kTimeoutMs);

        armMotor.set(ControlMode.MotionMagic, targetPos);

}

We got snowed out today, and our arm is bagged up, but on Saturday when we unbag I will dial up the kTimeoutMs to something higher, and see if that works.

We set the timeout value lower because we were worried that in the worst case scenario we’d start to get 20ms loop overruns.

Thanks for the quick response, hopefully we’ll get this resolved early Saturday.

[ozrien]

Your configAllowableClosedloopError calls appear to be setting a constant value. They can move to robot-boot-up instead of the start of the command.