CAN Error -200

Hi everyone,

Does anyone know the cause for CAN Error -200. The error message from the Driver station logs is:
ERROR -200 CTR: No new response to update signal Talon SRX 41 ConfigPeakOutputReverse

The only info I’ve found from CTRE is here. But it wasn’t very enlightening as to why this error appeared.

Thanks,
Alex

This error code means that when you sent the command to the TalonSRX it did not respond to the command. (When a signal is sent on the CAN bus the CAN controller expects to receive an ack (acknowledge) frame back from the TalonSRX)

When my team experienced the error we just replaced the TallonSRX and it went away. We plan on doing further digging to see what might have caused it to start in the first place.

Another thing you might want to try is to factory reset it though we have not tested this method specifically.

Hope this helps.

Thank you for your response. I figured that was what the error meant. We, unfortunately, have had the error appear sporadically on several different Talons. Not that we’ve replaced the Talons, but that different Talons on the robot have thrown the error at different times.

Because of this inconsistent behavior, I was hoping someone could explain reasons that the Talon might not respond with it’s ack.

Also (I won’t have access to logs until tomorrow to be sure), but I’m told that it is only occurring on the competition robot, and that they have not observed this error at all on the practice robot.

I would go through the whole CAN bus and check every connection to make sure there are no wires coming loose. Try taking everything off the bus then start adding pieces back on until you start seeing the errors again. Make sure you’re terminating the bus with a 120 ohm resistor (either by ending with the PDP with the jumper set to ON, or by turning the PDP jumper off and adding your own)

Just to double check - firmware on all CAN devices and the CTRE libraries - are they up to date with latest?

^ Team Update 14.

General
• CTR Electronics Software Update: An issue has been identified in the interaction between the
roboRIO image and the CTR Electronics Phoenix software that can result in CTR Electronics
CAN Motor controllers failing to properly enable, and an error being reported to the Driver Station.
While the exact source of the issue has not been determined between the two components, CTR
Electronics Phoenix versions 5.2.2.0 and later contain a patch that reduces the likelihood of
occurrence. Teams are strongly encouraged to either update to Phoenix 5.2.2.0 or to learn how to
circumvent the issue by reading the additional information found in the CTRE Phoenix
documentation under Driver Station System Watchdog -63194.
1 Like

I was told as a CSA that THE CTRE bug always throws that error code (63194), so if you don’t see that specific error code then it’s something else. Has anyone heard of that error happening without seeing that error code? (If so, how did you identify it)

OP, did you see error code 63194 also or just 200? What version of Phoenix are you using?

I am debugging remotely, but I am told that at the end of Smoky, they redid all of the cabling on the CAN Bus, and the problem persisted. Furthermore, I now have all the logs, and it seems that the problem has never occurred on the practice robot.

I have not seen that error code in the logs as of yet, but will keep on the lookout for it as I continue to sift through them.

I will have to wait on the answer as to which phoenix version we’re using. Regardless, I will make sure that it is updated to that version if it hasn’t been updated yet. Same goes for firmware of the Talons.

If anyone else has suggestions, we’d love to hear them.

What’s your CAN bus utilization (you can get the % from the Driver Station)? We experienced this problem today when setting the status and control frames for the talons to very low intervals. Reducing the overall CAN utilization fixed this problem.

Also, you only mentioned the error for ConfigPeakOutputReverse. Does this happen with any other configuration settings? Does this happen consistently to the same setting(s) across power cycles?

We are in communication with CTRE Support. But I’ll update where we are here, as we’re not 100% sure of the root cause yet. We only see the error with config messages. Our timeouts for the config methods is either 0 (don’t wait for an ack) or 10ms. Since the error is from our config messages, it only occurs at startup, but it is inconsistent across power cycles. Sometimes there is no error, sometimes there is 1 or 2. If there is an error it can be on any of our 6 Talons that has a config with a 10ms timeout, and has happened from several different config methods. My understanding from CTR is that 10ms is more than enough time to receive an acknowledgement.

The CAN Bus utilization is around 50-60%. rio CPU utilization is about 70-80%, but about 90% at startup. However, this error has never occurred on the practice robot, and according to the DS Logs, the CAN and rio utilization have similar values on both the practice and competition robots.

While at competition, the team verified that the all of the Talons were appearing the web dash, so the Talons aren’t disappearing completely from the bus.

The working theory at the moment is that for some unknown reason, on the competition robot either the Talons are sometimes not receiving the config messages, the ack messages are returning slowly, the ack messages aren’t being sent sometimes, or the rio does not receive the acknowledgements sometimes.

If anyone has an idea why any of these things could be happening, it would be appreciated. But in the meantime, on thursday, we will be trying to set all of the timeouts to either 0 or something absurdly high like 50 or 100 in an attempt to mitigate the issue (since, in my understanding, the config values hold between power cycles, and we aren’t updating those very often).

If you have sporadic CAN communication problems, look for a physical problem with the CAN wiring somewhere at the other end of the bus. A loose connection, or a missing terminator, or some other small wiring issue, can cause errors in communicating with devices that are far from the cause.

Also make sure you have good power to the devices suffering from the error.

OP. Did you or CTRE ever find a root cause or solution to work around this -200 CAN Talon error?

Sounds dumb to ask but have you wired the Talons sequentially with the 120 ohm termination resistor (PDP jumper)? I know alternatively you can wire it automotive fashion (page 37) with each device tapping off the “main” CAN wiring.

Below in the manual it details how a Branch or Ring setup of the CAN network shouldn’t be used. Just a random guess but given the latency and “randomness” of the location of the error it seems this could be a possible culprit. Just thought I’d throw it out there.

CTR ran our code on their practice set up. And they were able to reproduce the -200 errors. By increasing the timeouts to 50ms, the errors disappeared.

It is likely that the configs are(for whatever reason) acknowledging just barely over 10ms, since it is happening so sporadically, and then never when the timeout is increased to 50ms.

I still find it interesting that we could not reproduce the issue on the practice robot, yet CTR could reproduce it on their setup.

Sounds dumb to ask but have you wired the Talons sequentially with the 120 ohm termination resistor (PDP jumper)? I know alternatively you can wire it automotive fashion (page 37) with each device tapping off the “main” CAN wiring.

Below in the manual it details how a Branch or Ring setup of the CAN network shouldn’t be used. Just a random guess but given the latency and “randomness” of the location of the error it seems this could be a possible culprit. Just thought I’d throw it out there.

The competition robot was originally wired in the “ring” configuration. But after one of our regionals was completely rewired to the sequential method in hopes of eliminating these errors. This did not affect the -200 Errors. I believe the practice robot has been wired in the “star” configuration the whole time.

AlexD, it sounds like we’re on the same team (!). We haven’t seen these -200 errors on our PraticeBot EVER, but it keeps showing up on our CompBot. Our CAN is wired in a ring topology and the problem appears intermittently. We are checking all the wiring and encoders now and are bumping our timeout up to 50ms as CTRE suggested. We’ll see.

A 3rd talon replacement, wire check and the 50ms CAN timeout increase did not help our cause. We are going to review all we know and check our code.

Don’t do that. CAN isn’t meant to have loops. The transceivers want to see the right impedance on the cable (twisted pair wiring gives 120Ω), and without terminated ends on the bus there are going to be odd reflections and self-interference with the transmitted signal.

Unterminated branches on the CAN bus are “okay”, as long as they are short (less than a foot for a 1Mbps signalling rate), but I think it’s simpler to keep everything in a simple chain from device to device.

Alan, thank you for the response. ** I incorrectly used the word ring. Our Talons’ CAN bus is a linear, sequential chain topology **with the PDP supplying the needed 120ohm resistor.