ACIS Door Operations Discussion

Bob Goeke
Latest update: Sat Aug 22 13:44:30 1998 EST

Experimental Constants

Fudges to Nominal Time Calculations

Fundamental Approaches

  1. Single shot; what all the rest of AXAF does.
  2. Multiple shots of increasing length, each starting from a cold state.
  3. Multiple shots of constant length, each following the previous before significant cooldown can occur.

The ideal case would be to operate the mechanism at a continous, slow rate such that the operator would have plenty of time to observe the time/temperature/motion curve as it happens and thus validate the operating conditions. The conditions observed would include

Case 3 -- Multiple Hot Shots

This is typically used in cases (esp. in missions which lack a name) where a suitable bus voltage adjustment is not available. If a (normalized) 20 second pulse is applied, for example, the actuator would heat 15C during it's initial phase, or increase torque by 26 in-lbs during stall. Such a pulse issued every 3.5 minutes would walk the actuator through its travel range in 7.5C/13in-lbs/10deg steps. The command protocol is fairly simple to implement in that one needn't know a priori the starting temperature, and it matters little if the pulses deliver 25% more or less energy than nominal. A single 20s on/off command with a 3.5 minute trailing delay repeated n times would serve.

Assuming a starting temperature of 15C, the sequence of event would be like the following:

Pulse No. Total Time
Peak Temperature
Running Angle
Stall Torque
1 4 30 0 0
2 8 37 0 0
3 12 45 0 0
4 16 52 0 0
5 20 60 0 0
6 24 67 0 0
7 28 75 10 6
8 32 80 20 13
9 36 85 30 19
10 40 90 40 26
11 44 95 50 32
12 48 100 60 39
13 52 105 70 45
14 56 110 80 52
15 60 115 90 58

Of course, a 10 second pulse applied every 2 minutes would serve, also, with the advantage of keeping the actuator operating along a smoother temperature curve. Given the quantization of the command system, this is probably about the smallest pulse one would want to entertain; one also needs a minimum of two major frames between pulses to get the switch transitions properly recorded.

Case 2A -- Many Cold Shots

This approach can be used when a lot of time is needed between applications of power to determine whether things are going according to plan. The problems, however, are manifold.

Case 2B -- A Few Cold Shots

If one is simply trying to do the minimum, where the sole purpose is to avoid blowing the rupture disk, one could do less than the program outlined above. In this case a pulse is applied which is predicted to cause motion, but which -- in case of a complete stall at zero travel -- will not lead to failure. One desires a pulse limited to that which will generate a force one-half that necessary to blow the disk: 135 normalized seconds for a stalled output torque of 45 in-lbs. But one also needs to get the door to move, for which we need to generate about 22 in-lbs, which happens at 115 normalized seconds. To stay in between these two numbers the available data says:

Running an intermediate pulse into the actuator (say 100 seconds) provides little data, but complicates the above calculations in that the starting state for the 125 second pulse is mechanically different that that for which we have experimental results. Further, since the elapsed times between pulses must be long, we do not gain any worthwhile calibration of the pulse length as a function of initial temperature and bus voltage. In general we wind up sending one (failure) critical command whose particular parameters have never been exercised before.

Case 1 -- One Shot

This is the way things are done for the rest of AXAF, probably because no failures were observed in Thermal/Vacuum testing -- since they weren't exercised there. Of course, it's the way we always did it too, and it has a demonstrated reliability exceeding 95%.

The Starsys Ambient Stalled Actuator Data

This test data (provided by Neil Tice) is my source for the stall torque versus time numbers. Note that the indicated temperatures are somewhat lower than we are used to reading on our EGSE display; I've used our calibration curves in the handwaving conducted above.

Data Plot

Comments Received

Neil has pointed out that my fudge for voltage variation wasn't right since the actuators don't follow normal laws of thermodynamics -- a 7% error in timing in the calculations between 28VDC and 32VDC.

It was perhaps not obvious from my initial exposition that the ground-to-spacecraft command requirements are not significantly different for these several cases. Even Case 3 is simply a single ATS which is preloaded and started by a single command (and aborted by another single command).

The OCC people will probably be unhappy to know that there are some who are very concerned about OCC's ability to command the spacecraft on orbit, or to make decisions in anywhere near real time. These folks favor Case 2B because OCC only has to get a single non-time-critical command sent and it doesn't require the ground to send a second command to turn off power if things go wrong. The logical error in this is that one is only protecting against the problems you know (if anything new/unexpected happens during the "magic" 135s, you've had your hands in your pockets while it occured). The other logical error is that it assumes that the OCC is highly reliable in generating a "new" command sequence; to the extent that data exists, history has shown the opposite, and there are structural reasons within the OCC operations why this is true. The OCC people do not share these concerns about commanding reliability, but for the pessimist there is the additional consideration that a lot of ACIS commanding will have been done prior to the door opening. If the command process is not reliable, one would be well advised to solve the root problem first. Finally, the OCC has successfully practised the "emergency actuator off" command scenario on far shorter time scales than Case 3 would require.

Getting back to basics, one needs to ask: what is the best way to operate a Starsys actuator? The answer, it would seem, is a) to use it the way it was designed; and b) to collect as much data on its operation, as and as often, as possible. The Case 3 scenario responds to this, especially if you do all of the Starsys operations according to the same protocol. Not only do you get all of the valve openings and closings as well as the door closings, but you get them with a consistent protocol, not one that changes for every set of initial conditions. Craig Staresinich points out that the "failure of the DSN" Casandras can be accomodated by making the protocol:

There have been 70 accesses to this page since 9/14/2022.