Use of JoystickButton in Command Based does not activate PCM

[KPSch]

The issue we're seeing is that when a JoystickButton is added to the scheduler (ex. myButton->WhenPressed(new MyCommand())), the PCM does not activate.

The status lights for devices:
PCM:

Status: Green Slow
Comp: Off

PDP:

Stat: Green Strobe
Comm: Green Strobe

roboRio: Off
RSL: Blinking - Robot On and Enabled
Voltage Regulator:

5V: Bright Green
12V: Bright Green

Firmware:

PCM: 1.59
PDP: 1.40
roboRIO: 2.1.0f3

roboRIO Image: FRC_roboRIO_2015_v23

Observations:
The PCM does not activate after:

A complete power cycle of the robot.
Reboot roboRIO

The PCM does activate after we:

Deploy code.
Restart robot code.

Things we've tried that didn't work
Multiple PCMs.
2.4GHz WiFi
5GHz WiFi
Multiple Radios.
3 different WiFi channels - auto, 4, and 8.
3 different joysticks (traditional and an XBox 360 controller).
Tried relocating radio on robot.
Another laptop with fresh WPIlib and NI installs.
Manually instantiating the compressor with the C++ Compressor class.
Tried manually adding the JoystickButton to the Scheduler using Scheduler::AddButton() instead of JoystickButton::WhenPressed().
Another compressor.

Things we've tried that work consistently
Ethernet Tether.
Iterative.
Restart robot code. In fact, after a power cycle if we click Restart robot code before enabling, it works every time.

Things we have not tried
Another roboRIO.
Another PDP.

At the beginning of build season, we were able to wire and re-program a previous robot (with pneumatics) and did not have any issues.
We then wired and programmed this years' robot. We did not notice any issues until we got the pneumatics hooked up on this robot.
We consulted a local team that beta tested the roboRIO. Their programming mentor was also stumped.

In our troubleshooting, we created a bare bones Command Based project:
https://github.com/FRCTeam1987/PneumaticsTest

We found that in OI.cpp, we can create a Joystick and a JoystickButton just fine. The issue arises when we add a button to the scheduler, which is line 8 in the linked project.
Through NetConsole, we have seen that the code does run when we enable on a power cycle and the compressor closed loop is on, but the compressor does not turn on and the control system status indicators are as described above.
The PCM does get a sticky fault saying "Comp Curr Too Low - Most likely the compressor is not connected." We have also cleared the sticky faults manually using the roboRIO web page with the self test button.

What are we missing?
Does anyone have any suggestions for what else to try?

We are out of ideas to try and resolve this issue. Any help you all could provide would be much appreciated.

Thanks.

[ozrien]

I deployed it on my robot and haven't seen the symptom yet. I'll keep messing with it though.

I don't think this is part of them problem but thought I'd mention...
R60 - PCM must be updated to at at least version 1.62.
http://wpilib.screenstepslive.com/s/...ribution-panel

[KPSch]

Omar, thanks for the response and for trying the code on your robot. I can't find the firmware file for the PCM on CTRE's web site. Do you have a link? I looked here - http://crosstheroadelectronics.com/control_system.html.

[ozrien]

It's in the documentation-link I sent...
http://wpilib.screenstepslive.com/s/...ribution-panel

CTRE Devices use a file format call CRF (Cross The Road Firmware). Using the dialog, browse to the correct location on your computer and select the new firmware file, then click Open. Firmware for CTRE devices can be found in the C:\Users\Public\Documents\FRC folder.

[bob.wolff68]

I think the problem you're seeing is the same that we scratched our heads on for a while... this year there is no Compressor class. This year, you hook the pressure switch to the PCM and the power from the compressor to the PCM. Then in your code, the MAGIC (ok it's not magic - it's a matter of reading the right paragraph on the right page of screensteps - sigh) is to instantiate a Solenoid.

You don't even need to USE the Solenoid...just instantiate it in your robot class and then enable the robot.

Solenoid testCompressorTurningOn;

[ozrien]

Originally Posted by bob.wolff68

I think the problem you're seeing is the same that we scratched our heads on for a while... this year there is no Compressor class. This year, you hook the pressure switch to the PCM and the power from the compressor to the PCM. Then in your code, the MAGIC (ok it's not magic - it's a matter of reading the right paragraph on the right page of screensteps - sigh) is to instantiate a Solenoid.

You don't even need to USE the Solenoid...just instantiate it in your robot class and then enable the robot.

Solenoid testCompressorTurningOn;

...no ... they have a DoubleSolenoid in their ExampleSubsystem, which is instantiated in CommandBase::init(), so that seems ok...

Are you guys still having the symptom with the simple example you posted?
I haven't seen it misbehave yet.

[bob.wolff68]

If you are hearing the compressor start and your solenoid is in your command class(es), I think a simpler test is in order. Instantiate a Solenoid (or DoubleSolenoid) in the robot template code itself just for the sole purpose of seeing if the compressor will kick on. If it does, then there's a problem with how you're operating the commands. They can be tricky.

As for our simple example - I'm unaware if the team posted something that you're referring to. (blush).

bob

[KPSch]

Omar, I installed the PCM firmware update tonight. The problem has not gone away. We're now at 1.62 on the PCM.

[ozrien]

Are you seeing the same problem with the EXACT sample project you posted earlier? Where you enable the robot and...
- PCM reports not enabled in the self-test
- PCM status LED blinks slow green [or orange if sticky faults are set] instead of fast green [enabled].
- solenoid led does not turn on when button is pressed (every solenoid channel has a red led at the case edge of the PCM).
All three symptoms are occuring? Or some of them?

Does the PCM still show up in the web-based config?
Is it's device ID zero?

[KPSch]

Originally Posted by ozrien

Are you seeing the same problem with the EXACT sample project you posted earlier? Where you enable the robot and...
- PCM reports not enabled in the self-test
- PCM status LED blinks slow green [or orange if sticky faults are set] instead of fast green [enabled].
- solenoid led does not turn on when button is pressed (every solenoid channel has a red led at the case edge of the PCM).
All three symptoms are occuring? Or some of them?

Does the PCM still show up in the web-based config?
Is it's device ID zero?

We tested it with the exact same code and it still didn't work. The code didn't fire the solenoid so we modified it to do so. Following your suggestions, we ran a self test while the robot was enabled. It said the PCM was not enabled, but everything has worked fine since that self test.

We've run that self test a few dozen times over the last five days. This is the first time we've run it while the robot was enabled. Could that have made a difference? We don't understand why it's not happening now. We've pushed other projects and it's working in them too (it wasn't before).

We've power cycled the robot a dozen times since then and the compressor has worked every time. Go figure.

[Jared]

Reformat/reimage the roboRIO. I had a really, really weird intermittent CPU usage and CAN bug that went away immediately after I deployed code or restarted it, but came back if I power cycled the roboRIO. It's exactly like you're describing- the code doesn't work right if the robot starts from a cold boot, but it works if the code is started after the controller fully powers on. Something different with CAN happens when the code is started by the deploy sequence vs. a cold boot.