🚀 go-pugleaf

In article <C0AGzD.GtH@watdragon.uwaterloo.ca>,
 kcwellsc@watdragon.uwaterloo.ca (Ken Wellsch) writes:
> You don't say anything about the history of the drives.  We here at U of
> Waterloo have loads of RD53's that have the same behavior.  [...]
> So my guess is you've received these drives with
> this condition (i.e. they did the same in their DEC equipment as well
> which maybe why you've now got them?)

No, actually they were working fine on the RQDX3 controller some time ago.
They were removed from service when I got one ESDI drive + Q-bus controller for
essentially free, said ESDI drive being bigger and faster than all of the 
RDnn drives put together.  They sat on the shelf for a few months.  Very
recently I've had a need to throw together some low-end PCs, and I had these
drives, and I have pressed RD53's into PC service before... 

I'd suspect "stiction" or some such from the long "shelf time", except that
one of these drives formatted successfully on the PC before acquiring this
"won't stay spun-up" disease.

> The current theory is this: these Micropolis 1325's and 1335's apparently
> have quite sophisticated current sensing circuits to monitor the motor
> load and such.  With time, the motor windings degrade and the current
> load exceeds the tolerance of the limiting circuit.  The spin-up spin-down
> behavior is the drive saying I am not working correctly.
> 
> I've also heard about these puppy's having thermal troubles as well, they
> run for a while then spin down.  I think it may be a similar problem.
> 
> Indeed as others have pointed out, they do draw a heck of a current normally
> as well -- 2.5A as +12V normally.

Thank you to EVERYONE for the information so far.  

(This is the sort of problem that's more annoying than I really have time for.
70 MB of disk for a PC just doesn't cost that much nowadays; I don't really
*need* to use these big, power-hungry, slow drives... but now that this
problem has surfaced, I want to understand it, if only so I can avoid it in the
future!)

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
drivers, internals, networks, applications, and training for VMS and Windows-NT
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh