motors enabled while cRIO reboots (Safety hazard)

[byteit101]

When we reboot our robot via the "Reboot cRIO" button on the DS, motors (relays) revert to pre-disable state.
for example, we have a compressor and a harvester that are on the relay modules, and while testing, may disable the robot while not turning them off. when we hit reboot, if the harvester was on before we disabled it, it will turn on again, and stay on until the cRIO loads (not sure if it stops at FRC_NetworkCommunication.out or FRC_UserProgram.out, but its one of the two). unplugging ethernet cable, flipping switches does nothing (as expected).
This is a real safety hazard, and we have duplicated it on two seperate robots, with different cRIOs, different Sidecars, different modules, and different cables.
The relay lights on the sidecar are on.
Any idea how to fix this?

[RufflesRidge]

A way to address the safety hazard is to set these to off in your Disabled method. That doesn't really solve the root problem though which FIRST has to take care of. I would file a Bug Tracker ticket for the appropriate language on the WPILib project.

[Greg McKaskle]

What language are you using?

Greg McKaskle

[byteit101]

C++

[Greg McKaskle]

When the cRIO reboots, all code, even FRC_Communications is halted and the OS image is reloaded. The FPGA is also reimaged. During this time, the digital sidecars enable line should prevent the relays from being on. A few times in the past, we have seen sidecars where the enable line was blown or shorted, not sure which as I'm the SW guy, and this would mean that in a disabled state, the relays were live. It seems unlikely that this would happen on two sidecars. It also seems unlikely that this is new or has been there the whole time.

Please try with a trusted sidecar, and can you give details on what the direction of the relay was?

Greg McKaskle

[Al Skierkiewicz]

byte,
You didn't wire your motors from one output of the relay with the second wire going back to the PD did you?

[byteit101]

Originally Posted by Greg McKaskle

A few times in the past, we have seen sidecars where the enable line was blown or shorted, not sure which as I'm the SW guy, and this would mean that in a disabled state, the relays were live. It seems unlikely that this would happen on two sidecars. It also seems unlikely that this is new or has been there the whole time.
Please try with a trusted sidecar, and can you give details on what the direction of the relay was?

direction was forward, and it had a green light. I'll need to check what happens to reversed values tomorrow though. I'll also try with another spare DSC.
When not rebooting, things work normally

Originally Posted by Al Skierkiewicz

You didn't wire your motors from one output of the relay with the second wire going back to the PD did you?

No, Its wired -batt => -v spike -m => motor => +m spike +v => +batt

[Racer26]

I saw at least one robot at GTREast that had a motor continue running AFTER the end of a match, while I was on the field resetting. EVEN when its associated DS had been unplugged. I didn't understand how it could even happen on an inspected robot. I told the FTA about it, and don't know what became of it.

[byteit101]

Originally Posted by 1075guy

I saw at least one robot at GTREast that had a motor continue running AFTER the end of a match, while I was on the field resetting. EVEN when its associated DS had been unplugged. I didn't understand how it could even happen on an inspected robot. I told the FTA about it, and don't know what became of it.

Hmm... not us. We've only been to Smokey Mountains. Interesting to see it happening on other robots...

[linuxboy]

Originally Posted by 1075guy

I saw at least one robot at GTREast that had a motor continue running AFTER the end of a match, while I was on the field resetting. EVEN when its associated DS had been unplugged. I didn't understand how it could even happen on an inspected robot. I told the FTA about it, and don't know what became of it.

I've seen this with motors on speed controllers (jags I think), where a metal wharf will get in the speed controller and fry something (a FET I believe, but I can't tell you why) and permanently close the circuit that the speed controller controls. No control (ie stop) signal will change this. I'm sure one of the more experienced guys on here can speak to the exact happenings when a metal wharf gets in a speed controller.
- Oliver

[Al Skierkiewicz]

Originally Posted by 1075guy

I didn't understand how it could even happen on an inspected robot. I told the FTA about it, and don't know what became of it.

Phil,
There is no check (and no way to check) in the inspection procedure that tests for devices that continue to run. We do check for the correct firmware versions and check that any Jag using CAN has the correct version for FRC. It is possible that either a failure had occurred in the controller or that the team swapped in a Jag in CAN mode that did not have FRC firmware. The Jag firmware insures that all output is disabled when the Crio issues that command.

[byteit101]

Just as an update, we put in a completely different sidecar and it stopped enabling on reboot. Apparently we have two broken sidecars...

[Al Skierkiewicz]

byte,
Was your sidecar a 2012 version?