My team is having some serious canbus connection issues, what are the steps we should go through to work out any mechanical connection or other issues?
You might want to describe the methods you are using to wire the bus. The wire connections at the roborio and PDB and PCM, with the push in Wago connectors, require the wire to have the correct amount of insulation removed from the end, and should hold firmly enough that you can’t pull out the wire with a gentle tug. The plug in connectors that are included with most speed controllers need to have the two colors connected properly, yellow to yellow, green to green, and also they need to have some tension when you try to pull them apart–they should not be loose.
If you are soldering, whoever does the soldering needs to know what they’re doing, to make a good connection. If you are using some other type of connector, you need to make sure the wire is prepared properly, and installed correctly.
Also, are you using a “daisy chain” or “star” topology? that is, are all the devices connected in one long string, or are they all tied to one point?
Pictures help, also…maybe we can see something that you don’t know to look for.
1 Like
I teach my youth to look at the CAN bus as a loop that begins at the Rio and ends at the PDP (we daisy chain). Starting at the Rio, inspect the lights on each device to see if they’re indicating an error. It’s usually pretty clear where the break is, so fix that and keep moving on.
At the break, you’re looking to make sure the wires continue as yellow to yellow and green to green. Make sure the wires are still twisted and that the connectors are snug. Gently push and pull on the connectors to make sure it’s a solid connection. We moved to Waygo lever nuts this year after futzing with JST and solder in previous years.
Connections are usually the problem, but we also found a bad Talon causing problems last year and once we replaced it, everything worked.
At the ends of the loop, make sure it’s terminated. On the Rio, that’s easy since there are no options. We finish the loop in the PDP which means you need to use the inner connectors and have the jumper set to terminate. YMMV if you use a different termination device.
Phoenix Tuner is also a good tool to have since you can quickly see if you can talk to each device.
The key is to be methodical.
1 Like
Phoenix Tuner app also will be of some help (if you always starts from RIO and ends on PDP). Other than CAN devices that it doesn’t support directly, all your CAN device should shows up (RIO can see them all). So last device shown on Phoenix Tuner will be the last one that has the CAN bus wired correctly (or the device is acting properly). So you can work from that one towards the PDP. [Note, we have not tested all CAN devices and only know that the SPARK MAX does not shows up in the CAN Bus under Phoneix Tuner but it will be bypassed and continued on to the next device until the PDP].
Couple of other things to remember: CAN BUS requires a twisted pair to maintain the proper impendence so make sure that you don’t have stretches of CAN wirings that are outside of twisted pair (other than the connection points), If in doubt, only use Daisy Chain wiring method for CAN BUS.
@seanw @tkchan @MrForbes we are using falcons on our swerve modules, and in order to daisy chain the two motors on each module together we have connected the stock wires from the two motors together and then bundeed the ~two feet of slack right in between the motors. Could this be causing issues?
This is kind of what the bundle looks like:
Obviously, there are a lot more than just can wires in the bundles in this picture. Thoes are no longer like that as the power leads have been connected to the pdp and the first and las can connections have been extended to other modules.
I suggest you follow the troubleshooting steps outlined by others, as far as using the tuner to see the can addresses.
But as a general comment about electronic stuff…I consider it a good practice to always bundle signal and power wires separately. Wires that power motors can emit RFI, which signal wires can be sensitive to. I expect it’s more of an issue with brush motors, than brushless, but I’d still keep them separate.
1 Like
do you think having bundles of signal wires is a bad idea in general?
No, I don’t. As long as you can find the ends and make sure they’re connected as they should be.
those are all CAN bus wiring so noise pickup shouldn’t be an issue as long as they are twisted. Hard to tell from the pix, are the CAN wiring done in a daisy chained manner? i.e.
from left/previous CAN device → [top motor → bottom motor] → [ next top motor → next bottom motor ] → [ next-next top motor → next-next bottom motor] → [right side top motor → right side bottom motor] → to next CAN device.
I’m not clear on what the problem is. Can you see all the devices on your CAN network? When you send signals, do you get errors in your logs, and/or do lights come up on the Falcons? Do some motors turn? All of them? Intermittantly?
As tkchan said, CAN should be fairly tolerant to noise as long as the twists are maintained in the wire. I don’t like bundling wires with power either as you’re inviting noise and also make it harder to troubleshoot. I don’t even recommend bundling wires until you know it’s working.
Remember - a problem defined is half solved. Lay out your problem and what you expect to see.
4 Likes
Ask the most meticulous student and mentor to look over your wiring, one connection at a time. Do the tug-test @MrForbes described, one wire at a time. Do not stop after finding one error since there may be more.
Use a small, bright flashlight and look at where the wires go into the connectors to look for anything shiny. Do this from several different angles. A stray wire strand that did not go into the connector and/or wires with too much insulation removed will show up as a shiny points where shorts between adjacent wires can occur.
I’m not a software the guy, but the software guy isn’t a fan of forums, so I’m making this post. That said, afaik we can see all devices on the can network (8 falcon motors), can connect to them and make them all spin individually, and can make them spin while running code. The swerve drive in general is having some issues, which i think would be best described with a video, so i will get that, but the main CAN related error we are getting (again, afaik) is a “CAN Frame not received/too-stale” error, which appears while the swerve code is running. I am not sure if this error is given with a specific can device, but if it is, and if that info would be helpful, i can ask for that info.
I seem to recall that a section of the can wiring is currently being extended using a non twisted 3 conductor pwm extension… will get that fixed, and then report back.
Can frame not received / too-stale has some thoughts on what it could be (there are many possibilities). It should give you the CAN ID of the device which will tell you if it’s always the same one or not.
Definitely start by fixing that wire though!
yeah, ive seen that post. From what ive read, this issue is generally caused as a result of voltage sag induced by high load and the performance level lead acid batteries we use in frc, or just msc. wiring imperfections. i was under the impression though that about 24in of 12awg wire wouldnt be enough to cause this much voltage drop under normal circumstances, but am i wrong about that? I assume the falcon’s escs are smart enough to be able to regulate current draw, should i consider lowering this?
gotta ask sw man, but ill check on that this weekend.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.