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?
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?
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.
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.
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.