REV Pneumatics Hub Runs Compressor Unsafely — Warning

While testing our pneumatics layout in the new REV pneumatics hub, my programming students accidentally selected the CTRE parameter instead of the REV parameter when constructing the Compressor class in Java.

Besides experiencing your expected CAN errors in the DS console, I was surprised to discover that the pneumatics hub sends power to the compressor, even when the robot is Disabled, and even when the DS is fully disconnected from the robot.

I suspect this CAN interface mismatch is sending signals to the REV hub that falsely tell it to run the compressor. But I’m not sure if the hub’s overpressure switch detection firmware is in the loop when this happens, so I quickly cut power and released air before finding out if the compressor runs indefinitely.

However, this incident tells me that software errors through the CAN bus could cause the compressor to run in unsafe/undesirable conditions, such as when loading onto the field (FRC software has protections against providing motor power when the robot is disabled).

I wanted to make the community aware and was considering reaching out to REV about this condition in case a firmware update is required.

1 Like

Is this implying that you havent yet? I would do so if you havent already.


Reminds me of TikTok - Make Your Day


Please make sure firmware is up to date, and reach out to us at [email protected].

We will try to recreate this scenario, but we will likely need additional details. In your email to us, please include:

  • Confirmation of all software versions being used at the time of the issue (firmware, APIs, etc.)
  • A full copy of your code.
  • Detailed photos of your wiring.

I will, I will. I assumed the proper ConOp was to share information with “colleagues” and end users on CD first, then gather the data I need to inform the supplier when I have collected what they need to troubleshoot the problem. Like good ol’ aerospace government contracts.


Thank you, Rev. I will send you the firmware versions in use (latest one loaded but I dont have the number offhand), copy of code, photos of the setup when I can collect them this weekend.

1 Like

I attempted to reproduce this today, but was unable.

CAN - Rio (1) → PH → PDH
Power - PH from Port 20 on PDH
Also have voltmeter attached instead of compressor, and jumper wires instead of pressure sensor (so it can be manually controlled)

All firmware is up to date.
Rio image v3.0
WpiLibJ v2022.2.1
PH firmware 22.0.2
PDH firmware 22.0.2

Code is a fresh TimedRobot project with the ONLY addition being the construction of a Compressor object (new Compressor(PneumaticsModuleType.CTREPCM)) in robotInit()

Regardless of mode (disabled/enabled, auto/teleop, etc) or pressure sensor input, the multimeter remains at 0V. Also, the logs show “CAN: Message not found” repeatedly.

Once switching to PneumaticsModuleType.REVPH, everything works exactly as expected.

RoboRio: 2022_v3.0
PH Firmware: 22.0.1
PDH Firmware: 22.0.1

So I see here may be another software rev available out there, but the Rev Hardware Client doesnt seem to think so (See screenshot)

To demonstrate the condition, I restart the roboRio from the DS in this video. Once the DS lost connection to the roboRio, the Compressor powers on, and does not power back off until the roboRio is fully rebooted and in Disabled mode.

Is the rev hardware client still running in that video? The hardware client can enable the hub if no roborio is detected.


“Can”, or “does”? The sole purpose of running the client was to take screenshots of the firmware version. I should note that with no changes to wiring or the client, changing the single line:

Compressor comp = new Compressor(1, PneumaticsModuleType.REVPH); (Rather than CTREPH)

completely resolves the problem regardless of client connection status to the PH. In other words, loading the “correct” code to construct the compressor does not result in similar behavior when the roboRio is disconnected.
Having said that, I’m happy to demonstrate once again with no client connectivity, or potentially submit to the fact that this is not a universal problem but instead a potentially defective unit.

1 Like

Definitely try with no client connected.

With no correct compressor constructed, all the device will see is the universal heartbeat packet from the roborio, as that is sent by netcomm irregardless of what code is running. When you properly construct the device, actual pneumatic hub packets are sent. These packets are likely what locks out the pneumatic hub from accepting hardware client packets.

And the hardware client definitely does send heartbeat packets, but I thought there was a toggle in the pneumatic hub tab you had to select for it to do this.

I just did some testing with my device, and I do believe that is what is happening. If you keep an eye on the roboRIO Status indicator in the hardware client, you see that if there is no robot code running, it will say not present, and the compressor will be enabled. Once it detects a roboRIO, it will follow what the roboRIO is commanding. I also assume that the enable packet is always sent from the hardware client so solenoid toggling always works, assuming that you’re just benchtop testing a device.


Tested today, lo and behold – you were right, merely connecting a laptop via USB to the PCM resulted in the Compressor behaving this way. This was the case even if the hardware client wasn’t actively running, far as I could tell, but a USB connection still existed.
After removing the USB connection, the compressor ceased to run using the incorrect constructor param. Thanks for helping solve this mystery! I will let Rev know


Safety Minute: or Second? When working around automatic equipment like a FRC robot. They are not safe unless powered off. Maybe not even then, but that is a different question. This is the basis of the OSHA lock out rules.

Second safety minute.

R811 *Relief valve requirements. The relief valve must be attached directly to the compressor or
attached by legal hard fittings (e.g. brass, nylon, etc.) connected to the compressor output port.
Teams are required to check and/or adjust the relief valve to release air at 125 psi (~861 kPa).
The valve may or may not have been calibrated prior to being supplied to teams.

I would strongly recommend following this even in a setup that isn’t yet on a robot! If your tubing gets kinked or otherwise blocked, pressure can raise in the compressor almost instantly, and a relief valve will help prevent the compressor from becoming damaged.


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