Multiple pneumatics control modules?

[runger723]

Is it legal to use more than one pneumatics control module with the new roborio system? We need more than the 8 ports that are on this one. Thanks!

[adciv]

There is no rule against it and the system supports it.

[cgmv123]

Just make sure you start by connecting only one and changing the Device ID using the RoboRIO web interface. Two PCM's will work, but only if they have different Device ID's.

[tStano]

Also, the second one must be on its own circuit and not have a compressor. THis circuit can also support a combination of 2 PCMs(non-compressor) and/or VRMs(non-radio), Only one compressor is legal, and the rules state it must be on the one plugged into the weidmuller connectors.

[cgmv123]

the rules state it must be on the one plugged into the weidmuller connectors.

I see no requirement to power the compressor's PCM from the Weidmuller connectors, and R37 specifies the wiring of a PCM with a compressor into the WAGO slots on the PDP.

[Joe Ross]

Just make sure you start by connecting only one and changing the Device ID using the RoboRIO web interface. Two PCM's will work, but only if they have different Device ID's.

While it's true that the PCM won't work with your code while they have the same ID, it does not prevent you from connecting both and changing the ID of one from the web dashboard.

[tStano]

I see no such requirement, and R37 specifies the wiring of a PCM with a compressor into the WAGO slots on the PDP.

Yeah, you're right, I said the wrong thing. If you're additional PCM has a compressor, it needs to be on its own circuit, or in the weidmuller slot.

[GeeTwo]

Is it legal to use more than one pneumatics control module with the new roborio system? We need more than the 8 ports that are on this one. Thanks!

Just curious, but what's your general design? We've gone all-electric this year for the first time (our fourth; we have ONE four year robotics senior). Actually, this is a bit annoying to our controls mentor; even though he has an IBEW tattoo, he really likes pneumatics better.

BTW, our all-electric design is here (http://www.chiefdelphi.com/forums/showpost.php?p=1426595&postcount=40), though I believe we were planning a pneumatic brake at the time of that post. We're going with a servo-actuated pawl in the form of a ratchet wrench acting on a hex shaft. It'll be a bit more work on the programmers (stop it first, back up before releasing), but I hope we're up to it. :ahh:

[Al Skierkiewicz]

Max,
R68 Compressed air on the ROBOT must be provided by one and only one compressor. Compressor specifications may not exceed nominal 12VDC, 1.05 cfm flow rate.
You may write code to use a Spike (and or a direct pressure switch input to the RoboRio under R77), to feed the compressor if you like. The above rule is very specific in the "one and only one". It is specific to the point that you may not use another compressor to charge your system if you already have one compressor on the robot. An off board compressor must be wired using the pressure switch input described above and must be controlled by the RoboRio and powered from the robot battery as in the past.

[cgmv123]

Max,
R68 Compressed air on the ROBOT must be provided by one and only one compressor. Compressor specifications may not exceed nominal 12VDC, 1.05 cfm flow rate.
You may write code to use a Spike (and or a direct pressure switch input to the RoboRio under R77), to feed the compressor if you like. The above rule is very specific in the "one and only one". It is specific to the point that you may not use another compressor to charge your system if you already have one compressor on the robot. An off board compressor must be wired using the pressure switch input described above and must be controlled by the RoboRio and powered from the robot battery as in the past.

I was talking about powering one compressor, not using more than one compressor. Post edited for clarity.

[ElJeffe3255]

Team 3255 believes they found a bug in the Java library using multiple PCMs. When we created a DoubleSolenoid on each PCM, we told it which module for each solenoid as the first argument. Calling the set method to kForward or kReverse worked fine for both. But get always returned the same value for the solenoid on the 2nd module regardless of its setting. Taking a quick look at the Java source for WPILib, I believe it's always returning the value of the slots from the first module on a get. We worked around it by caching the state in a local variable. We plan on submitting a bug report (once we learn how to do that).

[ozrien]

If that doesn't work out, send me the example and I can post it on your behalf.
I'm not sure if non-beta teams can post bug reports.

support@crosstheroadelectronics.com