Certain Spark Maxes don't work through CAN bus

We are trying to run a single NEO using a Spark Max through code and the CAN bus. We have tested three Spark Maxes; one works and two don’t. All three run the motor manually through the REV Hardware Client. Everything is up to date, running 2024 firmware; we’re using 2024 WPILIB and REVLib. We have a Roborio 2.0

Here’s the code we’re running: GitHub - missfits/Robot-Code-2024 at zoe/simple-robot. We’re specifically testing the code in this branch; ignore the other branches.

2 Likes

I only see one Spark Max in your code. Can you explain in detail how you tested all three Spark maxes?

What do the LEDs of the Spark Maxes do when you test them?

We tested each Spark Max separately with the same code. We confirmed every time that the CAN ID was correct.

When the motors run successfully with code, the spark max light is green (occurs with one specific spark max). When they don’t and the code is running, the light is solid cyan (occurs with the other two spark maxes).
When the motors run through the REV hardware client, the light is cyan.

1 Like

Sounds like 1 (with green LED when driven) works, and the other 2 (with cyan LED) don’t. The cyan LED should really only appear in disabled (blinking cyan) or being commanded to 0 (solid cyan), assuming a brushless motor in brake mode.

When you say you’ve ensured the CAN ID is correct, are you changing it in code to match the device wired on the robot? Are you swapping the sparkmax on the robot? Are you reconfiguring the CAN ID of the sparkmark to match the value in code? Are they all wired on the same CAN bus at the same time or are you changing the wiring between tests?

The lights are solid cyan when the spark max is not working with code, yes.

We connect one spark max to the PDP and CAN bus at once; we switch the spark max out every time. The current CAN Bus setup only goes through 1 spark max. The CAN ID of the spark maxes were changed through the REV Hardware client to match the ID in the code.

1 Like

Today we tested a large majority of our spark maxes, with the same motor, same code, and one at a time (we switched out the singular spark max on the CAN bus). All of them ran the motor through the REV Hardware client and are updated to the latest firmware, but only half of them work through code (blinking green lights). The other half did not run the motor, and displayed a solid cyan. We haven’t found a pattern to which work and which don’t.

We have a couple new spark maxes but we have not tested them yet.

We also tried to reset the firmware on the spark maxes that don’t work through recovery mode. This didn’t change anything.

1 Like

If you run a SPARK Max through the REV Hardware Client, it needs to be power cycled before it will run with FRC code. Are you power cycling?

What firmware version, exactly, are you using on each of them?

Well, you’re still changing two variables at once. I recommend minimizing that change. Give the 3 sparkmaxes different CAN IDs, wire them all to the same CAN bus at the same time, each with motors, then just change code to reference the one you want to test.

Alternatively, you can give them all the same CAN ID and only swap out the hardware (spark max) between tests with the code being the same. Just make sure you’re restarting the code (or power-cycling the Rio or entire robot) between tests.

Edit: also what @gdefender said.

Yes, we are power cycling before running code. We’re using 24.0.1 firmware (seems to be the most recent update) on our spark maxes.

1 Like

Yes, we are doing the second suggestion. Sorry that it was unclear. All our spark maxes are using the same CAN ID and we are swapping them out and testing them one at a time.

1 Like

I would try adding a call to restoreFactoryDefaults(), just to be sure it’s not a configuration difference. It could be something as simple as a soft limit, or limit switch configuration.

Do any messages print to the console / rio log?

Thanks! We’ll try that at our next meeting.

If I recall correctly, nothing out of the ordinary; nothing unexpected is printed.

1 Like

If you are removing and swapping motor controllers I hope you’d be turning the robot off just as a general safety thing. Why play with live power when you don’t need to expose yourself to the hazard.

I would agree, but i added it because its not TECHNICALLY a requirement for that to happen. Deploying a code change is guaranteed to reatart code, however.

1 Like

I just want to add something here. The way the REV hardware client controls motors is the same method as the RIO uses. When you connect a SPARK Max via USB you are creating a USB-CAN bridge. We are sending the same CAN commands to each motor controller that are sent from the RIO. This means that if they work in the Hardware client they should work via code.

So to me it sounds like there is something going on with your on-robot configuration. If you are doing controller swaps when the robot is on, you will need to reboot them due to the heartbeat lockout (so the Rio and hardware client both can’t control a motor).

There is lots of good advice in this thread, but if you would like additional support please feel free to email us and we can have someone walk you through getting your setup running.

2 Likes

We have been power cycling the entire robot when switching out spark maxes and when unplugging the USB and plugging in CAN and vice versa.

@Greg_Needel, by “reboot,” do you mean restart the power to the spark max, or something else?

1 Like

Do you have a picture of your CAN wiring? Sounds like it could be something with incorrect connections. Is the PDP the end of the CAN bus, and is the terminating resistor jumper in the “on” position?

The CAN does end at the PDP; both the Roborio and PDP show up as part of the CAN Bus on the hardware client. Not 100% sure about the setting of the terminating resistor jumper–it should be on, but we should be able to get a picture of the wiring + PDP by the end of today.

Looks like it’s set correctly.