Compressor running in disabled mode

[Tom Bottiglieri]

We updated to the v27 cRIO image (using java dev) tonight and our compressor now runs in disabled mode. It still cuts off with the pressure switch. Has anything been changed that would cause this to happen? I know the compressor handler runs in a separate thread, but it doesn't seem right that it would override the disabled mode.

If not I suspect something funky is going on with the DSC.

[garyk]

Originally Posted by Tom Bottiglieri

We updated to the v27 cRIO image (using java dev) tonight and our compressor now runs in disabled mode. It still cuts off with the pressure switch. Has anything been changed that would cause this to happen? I know the compressor handler runs in a separate thread, but it doesn't seem right that it would override the disabled mode.

If not I suspect something funky is going on with the DSC.

We're seeing this on cRIO image v27 at 668 but not 3256, both running c++. We'll update to v28 http://firstforge.wpi.edu/sf/go/proj...1_0_for_2011_f and I'll post the results.

[garyk]

Originally Posted by garyk

We're seeing this on cRIO image v27 at 668 but not 3256, both running c++. We'll update to v28 http://firstforge.wpi.edu/sf/go/proj...1_0_for_2011_f and I'll post the results.

Sorry, I (as I'm sure are many others) am at school and doing too many things at once. As did Tom's (above), our 'bot cycled the compressor off as usual when pressure was reached. I visually confirmed the relay LED on the Digital Sidecar was turning on and off along with the compressor. (And the 'bot was disabled.) If it's not a software problem we can start addressing the Digital Sidecar as "Watson".

[Radical Pi]

I've heard of this problem before. The apparent problem was an internal short in the sidecar that cancels the signal to disable relay outputs. jhersh said in that thread though that the next cRIO image would fix the problem. Perhaps the fix got lost?

Running v28 and no problem here

[Mike Betts]

Team 3518 saw this occur once. It happened after a power cycle of the hostbot which, I believe, may have been too short to allow all internal components to reset.

I have instructed the students on my team to "count to ten" when cycling power on the hostbot. We have not seen the issue recur since adopting this procedure.

Regards,

Mike

BTW, the pressure limit switch did not stop the pump from over pressurizing the system when this was observed.

[Tom Bottiglieri]

Just a quick update. Our bot is still running v27. The compressor runs in disabled mode no matter how long it is off for.

Also, our robot drove in disabled mode at the suffield scrimmage.

[krudeboy51]

Originally Posted by Radical Pi

I've heard of this problem before. The apparent problem was an internal short in the sidecar that cancels the signal to disable relay outputs. jhersh said in that thread though that the next cRIO image would fix the problem. Perhaps the fix got lost?

Running v28 and no problem here

still having that problem in v28 for some reason

[Alan Anderson]

Originally Posted by Tom Bottiglieri

Also, our robot drove in disabled mode at the suffield scrimmage.

That's a hardware problem. First suspects are the Digital Sidecar or the 37-pin cable connecting it to the cRIO Digital I/O module in slot 4. Less likely would be the module itself, or the DB-15 connector it plugs into on the cRIO.

[RyanN]

Originally Posted by Alan Anderson

That's a hardware problem. First suspects are the Digital Sidecar or the 37-pin cable connecting it to the cRIO Digital I/O module in slot 4. Less likely would be the module itself, or the DB-15 connector it plugs into on the cRIO.

The sidecars are really finicky, aren't they? We blew out one of our DIO ports yesterday for no good reason at all. We had a standard limit switch connected between Negative and Signal. It returned a false at all times and caused a lot of panicking right before our unveiling. Luckily, we tried the port right next to it (DIO9) and reconfigured the programming for DIO9, and it now works . We're thinking of just taking out the programming for the limit switch altogether as it's not really needed.

So it wasn't electrical, and it wasn't programming.

[Alan Anderson]

Originally Posted by RyanN

...We blew out one of our DIO ports yesterday for no good reason at all...

So it wasn't electrical, and it wasn't programming.

Whenever I've seen a Digital Sidecar go flaky, it has always been traceable to one of two things. Either something put battery voltage on one of the pins, or there was metallic debris present.

Debris is almost always from careless drilling or filing. In both of the cases I saw where it was an accidental connection to battery, the root cause was someone working on the robot structure and letting wires flop around at random. So you're right, it wasn't electrical, and it wasn't programming. It was mechanical. Do we have a new scapegoat?

[RyanN]

Originally Posted by Alan Anderson

Whenever I've seen a Digital Sidecar go flaky, it has always been traceable to one of two things. Either something put battery voltage on one of the pins, or there was metallic debris present.

Debris is almost always from careless drilling or filing. In both of the cases I saw where it was an accidental connection to battery, the root cause was someone working on the robot structure and letting wires flop around at random. So you're right, it wasn't electrical, and it wasn't programming. It was mechanical. Do we have a new scapegoat?

Haha... sounds like it. We'll have to clean it out really well before we put it into the playing field.

[krudeboy51]

the problem is that for some reason the orange light that needs to go on the robot, when it is not lighting up when the robot is disabled or enabled, the compressor does not work

[billbo911]

Oh man, I wish ours would run in disabled mode. If it did, we wouldn't have to try to find the one tiny leak in our complex tubing system.

[garyk]

Originally Posted by garyk

Sorry, I (as I'm sure are many others) am at school and doing too many things at once. As did Tom's (above), our 'bot cycled the compressor off as usual when pressure was reached. I visually confirmed the relay LED on the Digital Sidecar was turning on and off along with the compressor. (And the 'bot was disabled.) If it's not a software problem we can start addressing the Digital Sidecar as "Watson".

668 upgraded to cRIO image v28 and the compresor-while-disabled stopped happening. In there somewhere we fried the Digital Sidecar and replaced it. I don't think the compressor-running problem was a bad Digital Sidecar - the relay for the compressor cycled on and off per the pneumatic pressure switch, and the relay LED on the DS matched the compresor's operation. It worked exactly as it should, the only problem was that it was happening while disabled. That being said, I can't prove it was the Image version and not the Digital Sidecar. Everybody is required to run cRIO v28 and I'm not going to experiment with v27 now. Maybe in the off season.

[plnyyanks]

reported