J. Kissel, T. Shaffer, J. Driggers, S. Dwyer

In addition to the one big blast of the PUM's Analog RMS Current Watchdog Trips this morning, at ~16:50 UTC (mentioned briefly in LHO aLOG 20654), we had three more instances of this silly watchdog tripping, which required drives to the end station.

Attached is a trend of the past 7 hours. The sad thing, is that there is no pattern. 
(1) The ITMs (Blue and Green) appear to *have* tripped when we've sent a blast to the PUM, but we've sent similar blasts since and they do not trip.
(2) ETMX (Black) has tripped when there is no signal sent to it.
This is why we always get into the blame game when we get a rash of these trips: 
- CDS says "What're you doing differently with the drive? It's gotta be you!" and 
- Users say "We're not doing anything different. It's a Tuesday! What did you do near these drivers?"
and nothing gets resolved.

Will someone please write an ECR to remove these Analog PUM WDs? 
The first action in said ECR should be to find what components this which dog is supposedly protecting, and to determine if it is actually protecting anything and/or if that component is actually in danger.
If first action deems that these are worthless, we should just rip them out. If-and-only-if they're not worthless and they're actually protecting some sensitive component that is unique to the PUM driver, then the second action would be to really study these circuits to understand what trips them, if the threshold is set correctly, and why there are so many false alarms. The third action should be, then, to fix them.

The Message: When these watchdogs trip -- especially when just one quadrant trips, and we send any number of large amounts of drive to the L2 stage, we ring up violin modes, and we suffer even more down time.