Happens when simulating and on the robot, pretty sure we updated our firmware
A number of things can cause this error
- make sure all of your firmware is updated
- make sure the PDP is CAN 0 and nothing has overlapping CAN id’s
- make sure everything is plugged in correctly. You should be able to trace CAN from you RIO through all of your components to your PDP
- make sure your CAN id’s in code match those in Phoenix Tuner and you have no duplicates or nonexistent devices
the self test feature in Phoenix Tuner can be very helpful for this kind of thing.
How do you make pdp can 0 if it doesn’t show up in tuner? Same with the rio
That’s a sign your PDP is not on the CAN bus. Make sure your CAN bus is correctly wired up, terminating at the PDP, with the terminating resistor jumper on.
It’s connected and terminated, all my motor controllers and pcm are there in the tuner
Not that this isn’t a best-practice, but is there a reference for this statement? We’ll eventually have to solve a similar issue on our bot. We allocate our PDP to ID 20; last year we could read the PDP currents just fine. We have yet to implement the PDP reader code this year, but plan to do so.
I’m reasonably sure it’s nothing more than a best practice. Some CTRE documentation even recommends leaving id 0 open to add a new device if you need to.
I have seen GitHub issues where it is suggested to set the pdp id to 0 and we always set ours to 0
Is there a program loaded into the Roborio with at least on instantiated CAN Device? The Phoenix Tuner now needs this to work properly and browse the CAN network this season. You could try to use one of the Load Temp program options found on the main page of Phoenix tuner.
You can and should leave the PDP at 0. Even then you can add new devices. As long as they are of a different type they will appear in the list. This is why its recommenced and works to have your first PCM also Node 0. A TalonSRX or other CAN devices will appear on node 0, but two Like devices on the network with matching node IDs will only show up as one device. This is when you hit the flash button. Locate the Device and address it accordingly to your teams mythology. We Address them to match the PDP port they are plugged into. This way when referencing them in Code, using the Driverstations logs, or other tools it all lines up cleanly.
What do you mean by
Since you are simulating, there are no Talon SRX encoders to simulate. If you want to test your code make a fake encoder and read the output.
Create an instance of a CAN object in your code.
1 Like
Why?
Robot code shouldn’t care, but it needs to be 0 for current logging on the driver station. https://docs.wpilib.org/en/latest/docs/software/can-devices/power-distribution-panel.html#creating-a-pdp-object
4 Likes
There’s no need to ever change it, outside of offseason applications with multiple PDPs. CAN IDs have two parts; one is the ID you know of that you set in Phoenix Tuner, and the other is hidden to the user and identifies what kind of device it is. Because of this, you can have a Talon, Victor, SPARK MAX, PCM, and PDP all IDed to 0 with no issues. It’s only once you add a second of the same device that you need to separate the IDs.
I believe the Talon SRX and Talon FX have the same device ID, in which case you do need to keep those separate.
Thanks! This is exactly what I wanted to know.
I can confirm that the Talon SRX and Talon FX are the same category of device as far as CAN IDs are concerned. We plugged a new Talon FX into a CAN bus that had Talon SRXs already ID’d and we received CAN errors as it conflicted with the Talon SRX ID 0. The Talon FX had to be set to a unique ID than the Talon SRX IDs.
Would have assumed CTR would treat the FX as a different category.
Thanks for clearing that up! I understand the rationale now
Just an update, stopped doing it when connected to the robot yet it will continue on sim. Probably because it is expecting an encoder even though it’s simulating it?