space@mvac.UUCP (Sci.Space netmail) (03/19/89)
This may be a nieve question, but I'll post it anyway: Countdowns for launches
begin much earlier than the time alloted in the countdown timer (ie a launch is
set for 72 hours away, but clock says T-50 hours, or whatever). I know that
'built in holds' are the reason why the two clocks do not agree, but my ques-
tion is why are they there? If you *know* that you are going to stop the clock
for 1 hour and 20 minutes when the countdown clock says T-xxx, than why not
just add one hour and 20 minutes to the countdown clock and just say that from
T-4:20 to T-3:00, there is no planned activity.
thanks,
- tom lapp
==============================================================================
(Nope, Reply will *not* work. Choose one from below to use for replying to
me).
uucp: ...!udel!mvac!space BITNET: space!mvac%udel.edu@CUNYVM
Internet: mvac!space@udel.edu
or
space%mvac.uucp@udel.edu
-------------------------------------------------------------------------------henry@utzoo.uucp (Henry Spencer) (03/23/89)
In article <8.UUL1.3#5131@mvac.UUCP> mvac!space@udel.edu writes: >... Countdowns for launches >begin much earlier than the time alloted in the countdown timer... I know that >'built in holds' are the reason why the two clocks do not agree, but my ques- >tion is why are they there? If you *know* that you are going to stop the clock >for 1 hour and 20 minutes when the countdown clock says T-xxx, than why not >just add one hour and 20 minutes to the countdown clock and just say that from >T-4:20 to T-3:00, there is no planned activity. There is no particularly good reason for this; it's just NASA tradition as far as I know. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
cew@venera.isi.edu (Craig E. Ward) (03/24/89)
In article <8.UUL1.3#5131@mvac.UUCP> mvac!space@udel.edu writes: >This may be a nieve question, but I'll post it anyway: Countdowns for launches >begin much earlier than the time alloted in the countdown timer (ie a launch is >set for 72 hours away, but clock says T-50 hours, or whatever). I know that >'built in holds' are the reason why the two clocks do not agree, but my ques- >tion is why are they there? If you *know* that you are going to stop the clock >for 1 hour and 20 minutes when the countdown clock says T-xxx, than why not >just add one hour and 20 minutes to the countdown clock and just say that from >T-4:20 to T-3:00, there is no planned activity. The story I got (sorry, I don't remember the source) was that in the early days, it seems that something would always go wrong so one team leader just said "We're going to plan to have something go wrong at this point." As to why not just add the time, they probably still kept the old schedule format out of habit (the old historical reasons). Also, if something does go wrong, it might not be fixable within the hold time. Craig -- ==================================================================== ARPA: cew@venera.isi.edu PHONE: (213)822-1511 ext. 111 USPS: USC Information Sciences Institute 4676 Admiralty Way, Suite 1100 Marina del Rey, CA 90292 Slogan: "nemo me impune lacessit" ====================================================================
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (03/24/89)
In article <8.UUL1.3#5131@mvac.UUCP> mvac!space@udel.edu writes:
: This may be a nieve question, but I'll post it anyway: Countdowns for
: launches begin much earlier than the time alloted in the countdown
: timer (ie a launch is set for 72 hours away, but clock says T-50 hours,
: or whatever). I know that 'built in holds' are the reason why the two
: clocks do not agree, but my question is why are they there? If you
: *know* that you are going to stop the clock for 1 hour and 20 minutes
: when the countdown clock says T-xxx, than why not just add one hour and
: 20 minutes to the countdown clock and just say that from T-4:20 to
: T-3:00, there is no planned activity.
Like Henry, I doubt there's any logical answer, but I think I can guess
why they decided to do it that way.
Psychologically speaking, it's more acceptable to stretch out an already
existing hold than to stop the clock when it is running. When the clock
is running, the default is for it to keep running. When it's stopped, you
have to take some positive action to restart it. For safety reasons, it's
probably better to vacillate on the question "Shall we proceed?" than on
the question "Shall we stop?", even though the launch will proceed only
if there's nothing to stop you.
It's a psychological gimmick, but if I were a launch controller, I'd rather
the clock weren't moving while I had to decide. A moving clock gives an
unwanted (I almost said "false") sense of urgency.
But it'd be nice if they'd show the public two clocks, the current one, plus
another that gave the minimum time to launch, labeled as such, that
stops at the end of the built-in hold if they extend it. After T-9 minutes
you would presumably have to show only one of them. (Unless, of course,
the countdown halts at T-31 sec, in which case the minimum time to launch
should pop back up on the screen, saying something like "2 days". :-)
Larry Wall
lwall@jpl-devvax.jpl.nasa.govbruce@idsssd.UUCP (Bruce T. Harvey) (03/25/89)
In article <8.UUL1.3#5131@mvac.UUCP>, space@mvac.UUCP (Sci.Space netmail) writes: > ... Countdowns for launches begin much earlier than the time alloted in > the countdown timer (ie a launch is set for 72 hours away, but clock > says T-50 hours, or whatever). I know that 'built in holds' are the > reason why the two clocks do not agree, but my question is why are they > there? I believe that in the 1940s and 1950s, when expectations were high, rockets were small, and men were very impatient, the scientists and engineers discovered that their "straight-through" countdown (i.e., with no planned holds) forced them to do _everything_ perfectly the first time. If there were any problems that took longer than a few minutes to fix, the launch attempt was thrown off track -- systems would start before the previous task was complete, and so on. As I understand it, the planned holds are both "breathing space" (where you can check in with everyone to make sure their part is finished) and "end-of-task-markers." The launch is divided into a series of tasks, each complete in itself, which is why you can hold at T-9 minutes for either 10 minutes or 3 hours, depending on what needs to be done. Once each subtask is complete, and is verified to be complete, and the weather is still good, then the count resumes. Without the holds, you would see many more aborted countdowns, I'm sure. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bruce T. Harvey (B-}> | ... cp1!sarin!wb3ffv!idsssd!idssup!bruce (Title depends on day) | ... ctnews!idsssd!idssup!bruce (301) 584-1960 | Convergent Route Distribution Sys. - Hunt Valley, MD
petej@phred.UUCP (Pete Jarvis) (03/27/89)
In article <1989Mar22.175252.1343@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > >There is no particularly good reason for this; it's just NASA tradition >as far as I know. >-- >Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology >passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu The buil-in holds are not there because of NASA tradition. They have a purpose in life. Built-in holds are designed into the count at key points in the launch activity sequence where they may need to do some catch-up activity. If the activity runs over the allotted time, then, depending on where the count is, they can decide whether or not to proceed at that point or re-cycle the launch sequence computer to an earlier mode. Peter Jarvis - Physio-Control -- Redmond, WA.
henry@utzoo.uucp (Henry Spencer) (03/29/89)
In article <2515@phred.UUCP> petej@phred.UUCP (Pete Jarvis) writes: >>There is no particularly good reason for this; it's just NASA tradition >>as far as I know. > >The buil-in holds are not there because of NASA tradition. They have a purpose >in life. Built-in holds are designed into the count at key points in the >launch activity sequence where they may need to do some catch-up activity... You miss the point. That's an excellent reason for having some slack time. The original question, though, was why the countdown clock stops during the reserve time. There's no obvious reason why it couldn't keep counting -- the lengths of those periods are fixed and predictable if nothing goes wrong. It's a bit silly to have the clock stopping and starting when everything is going according to plan. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
tneff@well.UUCP (Tom Neff) (04/05/89)
In article <1989Mar28.233955.1843@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <2515@phred.UUCP> petej@phred.UUCP (Pete Jarvis) writes: >>>There is no particularly good reason for this; it's just NASA tradition >>>as far as I know. >> >>The buil-in holds are not there because of NASA tradition. They have a purpose >>in life. Built-in holds are designed into the count at key points in the >>launch activity sequence where they may need to do some catch-up activity... > >You miss the point. That's an excellent reason for having some slack time. >The original question, though, was why the countdown clock stops during the >reserve time. There's no obvious reason why it couldn't keep counting -- >the lengths of those periods are fixed and predictable if nothing goes wrong. >It's a bit silly to have the clock stopping and starting when everything is >going according to plan. To understand built-in holds you have to understand the countdown. It is not like the game clock at Maple Leaf Gardens, ticking away oblivious to the action taking place down on the ice. Rather it is an intricate master *timeline* running down the left side (conceptually speaking) of a massive set of checklists. Every one of the myriad events and actions leading up to a launch has its own specific moment on the master timeline - its T coordinate, if you will. This is what keeps a launch organized, otherwise it would be hopeless because many steps are interdependent and doing them out of order would be fatal. Now when the checklists are created the T coordinates are assigned so they SHOULD correspond to real time if everything goes OK. In this ideal scenario you would start the countdown clock at T-24h0m0s or whatever, and it would unwind in real time right up to ignition. But frequently problems arise, major or minor, and a step needs extra time (real time) to finish. In this case three things can happen. The step could be a super critical one that lots of other things rely on (like spacecraft power or sequencing equipment), in which case you have no choice but to take an unplanned hold in the countdown while the problem is corrected; or it could be something with local scope, with just a few things relying on it immediately, so you may whip out the pen and move those things down in hopes the problem will go away before you have to hold everything; or the problem may be something that isn't a show stopper just yet but that needs to be handled before the next major phase of the countdown. In the last two cases you may need some slack time. Thus the planned hold. Planned holds are like expansion joints in a bridge, separating major countdown segments. They let you take a breath, nail down any remaining loose ends before proceeding with the next phase -- *without* messing up your intricately coordinated timeline. Since everyone is very busy with events right up the the start of a planned hold, the launch director will frequently take the hold for a couple of minutes just to go around the loop and make sure everyone's in shape for the next phase -- even if nothing's actually wrong. Sorry for the long windedness of this explanation but it's a frequently asked question, and I want to make sure the answer is thorough. If anyone has corrections or amplifications to this I look forward to reading them. -- Tom Neff tneff@well.UUCP or tneff@dasys1.UUCP
larson@unix.SRI.COM (Alan Larson) (04/08/89)
In article <1989Mar28.233955.1843@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >You miss the point. That's an excellent reason for having some slack time. >The original question, though, was why the countdown clock stops during the >reserve time. There's no obvious reason why it couldn't keep counting -- >the lengths of those periods are fixed and predictable if nothing goes wrong. >It's a bit silly to have the clock stopping and starting when everything is >going according to plan. A couple of reasons. o If the clock is stopped, and you extend the hold a short time, it is easier to continue with everything still on the time schedule than if you have to reset the clock to the end of the 'idle' time before continuing. o If the end of the 'idle' time is coming up, it is easier to continue the hold than to stop the clock. It has to do with the difference in answering the questions: "Is everything right" and "Is something definitely wrong". It is easier for someone to say, "Don't continue yet, we should check this", when approaching the end of a hold than to say "Stop the countdown, I want to check something." Alan