Wpilib Solenoids causing Error -1154: HAL: CAN Receive has Timed Out

Hello,

Our team has had reoccurring issues with our CAN bus. FRC driver station shows the error message “Error -1154: HAL: Can Receive has Timed out”, and the counter for TX Full increases by 3 per second. This leads to a general jerkiness in the drive train, compressor, and other subsystems. We believe that this is due to the CAN bus running out of bandwidth.

We went through each motor in our code and removed it in an attempt to decrease the CAN utilization, but nothing made a difference except for our Double Solenoid in our intake. This is the code we are using to create it:

DoubleSolenoid ds = new DoubleSolenoid(Constants.pneumatic_CAN_id, PneumaticsModuleType.REVPH, Constants.forward_channel_port, Constants.reverse_channel_port);

With this line, we get the can issues listed above, and our robot behaves erratically. As soon as we comment out this line, the can issue goes away and the robot behaves normally.

Is there any way to decrease the CAN utilization of a solenoid, analogous to Talon SRX’s setStatusFramePeriod(), or are we creating the Double Solenoid object incorrectly?

Thank you in advance, and best of luck to all teams this weekend!

You are creating the double solenoid fine. Make sure that the jumper on the pneumatic module is rated for the solenoid. From my experience with this error, it is because your compressor object and pneumatics module/solenoid object do not have the same can id that is shown in the Pheonix tuner. It also might be that you are doing something like this in one of your commands

@Override
public void execute() {
  ds.set(Value.kForward);
}

It isn’t like a differential drive, you aren’t supposed to set it in a periodic fashion.

Your assumption that the CAN bus is out of bandwidth is correct. I would start by increasing as many of the status frame periods on your motor controllers as you can. Pneumatics take almost no bus usage compared to motor controllers. (not a whole lot of status to report back)

Both of the above replies are possible. Please share your code (ideally as a link to github or similar), the full error output (including stacktrace if one exists. Check the console output/riolog, not just the DS), and a screenshot of the REV Hardware Client that shows the various device CAN IDs

Here is the link to our code: https://github.com/dgzct11/RapidReact5057/
The working version is the fixed_branch.

We aren’t even using the Solenoid object yet anywhere, we are just instantiating it. We ensured that the CAN ports for the pneumatics hub is correct, but we aren’t making a compressor in the code.

We already increased the status frame periods of most of our motors to 255 ms already, and we are getting the same issue.

How many motors do you have? You may simply be at a point where the bus is saturated even with high status frame periods.

The easiest solution would be to buy a CANivore and use it as a second CAN bus.

Before recommending products as a silver-bullet solution, I’d prefer to see the logs indicating CAN usage.

1 Like

Your Compressor is instantiated with a CAN ID of 1, but your DoubleSolenoid is using CAN ID 9. Do you have two Rev Pneumatic Hubs, or is one of those an error. If your Pneumatic Hub is not at CAN ID 9, that will cause that error.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.