[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: Dead G-5400B

>The KCT is an unsafe design. It has no failsafe against software upset. If
the software turns on a motor, and then crashes, as apparently happened to
you, the motors will be stressed and possibly destroyed. Also, a single
random port write is enough to turn on the motors, so it's not unlikely for
insane software to turn the motors on by accident. These risks are bad
enough under DOS where the KCT was designed to work, but they are absolutely
foolhardy under Windows. It was only a matter of time before somebody lost a
rotor that way.

I lost a few motors in this fashion.  Then, I quickly learned how to rewind
motor windings,
which is not a fun project.  However, it is definitely cheaper than
purchasing a new motor.
Usually when the windings heat up in the motor during a stuck condition from
the KCT or
a relay,  they start to melt the coating on the field coil wires until a
short develops.  At this
point, the motor does not work.  In each case you typically find 2 of the 4
field coils in the
motor to be bad.  The first time this happened to me, I simply replaced the
motor, but I
saved the defective motor.

The second time it happened, I took the 2 good field coils from the first
defective motor and
replaced 2 of the defective coils in the second motor.

The third time it happened, I learned how to rewind the field coils myself
and realized
soemthing needed to be done.  That is when I placed two limit switches in
the Azimuth
rotor.  Now when it hits the stop points on each end, the source voltage is
thereby defeating the possibility of frying a winding coil at the stop

My KR-400 in the G-5400B AZ/EL rotor set does not have limit switches in the
unit.  The
elevation rotor has limit swiches to prevent melting the winding coils.

The azimuth rotor in the G-5600B set already has limit switches designed in
the unit.

>Unfortunately, many rotor controller designs share these defects. Either
nobody sees this as a problem, or nobody wants to spend the additional few c
ents it would cost to add a hardware timeout to protect the motors.

The preferred place to put the protection is in the rotor as limit switches.
The software
timer circuitry would be helpful, but it will still heat the field coils in
the rotor if it is already
stuck and you have to wait for the timer to expire.  I would prefer software
that detects
movement when the field coils are energized.  If the rotor has not been
detected to
be moving in a small time frame, then it should stop it's action.  In the
case of stuck
relays in the control unit,  the limit switches in the rotor will prevent
the damage to the
field coils.  If the rotor does not move for any other reason to its stop
points, then the
limit switches will not help that condition.  Therefore, it is important
that the software
emplay a motion versus time routine.  If the rotor does not move in the
direction of
control within a short period of time, then it should cease its control

In each of my rotor failures, I have found the relays to be sticking in the
box.  These relays will be replaced with TRIACS in the near future as the

I seem to recall the old DOS based driver by N6KK, that I used with
checked to make sure the rotor was moving in a certain specified time frame.
If it was not moving I recall a CW beacon identified AZ or EL as the problem
you were not watching it.  More importantly, I think it stopped attempting
advance the rotor during this condition.  Maybe my memory is bad and it was
wishful thinking, because it has been some time since I used the DOS-based
control program.

>>My schematic
>>indicates a thermal fuse on the ground return of both rotors but the
>>parts break down does not list it. Can anyone shed some light on this?

The thermal switch has never protected my motor in the case of a switch

At one point, the transformer went bad in my old Kenpro KR-5400 years ago.
I replaced it with 2 from Radio Shack that had thermal protection and this
greatly reduced my rotor failure before I added the mechanical limit
in the rotor.  Two transformers were required since the original transformer
had 2 taps on the output and I could not find one to match it directly at
time that was cost efective.  The latter comment was the driving factor.

The 2 things I think that are important to prevent damage to the motor
windings are:

1) The rotors must have a limit switch to be protected from a controller

This failure could be caused by software, stuck relays, etc...  Software can
do nothing for a stuck relay, unless there is a master control relay or
of the controller unit.

2) The KCT driver software or any other driver softwrae should check the
rotor motion.  If the field coils have been energized, the software should
insure that the rotor is moving in the desired diercetion within  a small
window.  if it is not moving, then the softwrae should detect this condition
and not attempt to drive the rotor.

This failure could be caused by a mechanical failure, electrical failure in
rotor, heavy icing on the rotor, or any number of other conditons that
the rotor to move.


Tim - N8DEU
Huntsville, Alabama

Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org