PDH Hardware Fault

Has anyone encountered the PDH Hardware fault or know how to address it? The guide says
“The hardware fault is generally an internal electrical fault. This could also trigger a sticky fault if a large amount of electrical noise caused a brief communication breakdown internally. This will not affect the function of the device but there could be a small amount of data lost during the interruption.”
It will still run motors but i can’t figure out how to un-fault it. Also seeing (probably related) the low-power channels are showing as no voltage/no breaker even with breakers in.

According to the PDH docs:

Sticky faults are cleared when the mode button on the Power Distribution Hub is pressed or can be cleared using the REV Hardware Client. It is also possible to clear sticky faults using WPILib.

If the fault persists after clearing the sticky faults through the Hardware Client, please reach out to us at support@revrobotics.com so that we can help determine what is happening.

The hardware fault is a general fault that can mean a lot of different things, so we are planning a firmware update that will include fault codes that give more details. I don’t have a release date for this feature yet, but our goal is very soon.

A hardware fault on the PDH will not affect the power distribution capabilities of the main high-current channels or the three non-switchable low-current channels.

2 Likes

How soon, is soon? we are currently experiencing the same problem and have a week 1 event

As far as I know the faults do not impact the functionality of the pdh, so if it’s not fixed you’ll still be able to compete

We are encountering a somewhat similar issue - all “in use” channels, both low and high power, show blinking red fault LEDs and the hardware client shows “Was tripped or missing” - but we have “OK” for the current fault status. Current measurements work and appear normal. We can clear faults but rapidly end up back in the same state. I’ve been collecting information for REV support. They did assure me that the fault indicators are just indicators, and do not affect power distribution through the hub, so we’re not too concerned at this point.

FWIW, I’ve observed the same behavior on at least one other team’s robot.

We are on firmware 22.0.3.

Like firecrafty said, it seems to work anyway. Our low current channels constantly show solid red (breaker missing or no voltage) and the conclusion w/ REV is the current monitoring chip is faulty, but the PDH still delivers power over those channels

(I think) blinking red isn’t actually an issue. Docs say it just means there was a fault at some point. All of the active channels blink whenever we open and close the main breaker to turn the bot on or off. Blinking channels are still working. My guess is it was supposed to help detect which/if a breaker tripped but they didn’t realize it would count it as tripped whenever the robot was turned off or a breaker removed.
If the channels are staying red it’s an active fault, which is also the status when no breaker is in.

Ours is doing the same thing as yours, @phoenix22
all of the connected breakers blink red when the robot is powercycled, but once cleared they’re fine.

I believe you are correct, however I would not expect normal power cycling to produce spurious faults. (REV also confirmed that what I’m seeing is not “normal” behavior.) If they get the issue sorted out it’s actually a very nice feature to know which channel had a breaker trip, as well as the red light for active faults. Hoping they have a resolution soon, but we can certainly run with it as-is until then.

1 Like

You can do some nice things in S/W, including clearing and tracking faults. For example, clear faults in Auto/Teleop Init, and collect and print/log them in Disabled modes. This shows if any faults triggered during Auto/Teleop Periodic. Of course, there are other ways to manage things.

2 Likes

If our pdh is showing this fault, will we be able to pass inspection with it even if it is functionally operational.

There is nothing in the inspection checklist that requires the pdp to be free of faults.

Ours does this too. I was excited for the persistent visual indicator to a tripped breaker, but it’s nearly useless like this.

They definitely accounted for the breaker being removed, as it’s part of the fault description. There’s no real way to distinguish that from a breaker trip.

I would guess it’s just something wacky with the boot-up process, or even potentially something with residual current when power is removed. I imagine it’s fixable in firmware, hopefully by next season.

Ours does this as well. What we’re doing is clearing the sticky faults when the code starts, and before we shut it off when taking it off the field quickly check for any flashing lights and note which breaker positions so that we can match them up with the log later.

Something that we probably will implement at some point but haven’t gotten around to it is logging breaker trips by checking for faults in software

2 Likes

I’ve considered doing exactly this, and since I’m our drive coach I’m pretty sure I’d be able to always check it before someone forgets and turns the robot off first. However, that doesn’t help me much when helping other teams as a CSA - but I’m not doing that this year. Hopefully it’s fixed for next season.

1 Like