next up previous contents index
Next: CACOR: Integration Cycles Missed Up: Troubleshooting Previous: Delay Unit Control Computer:   Contents   Index


CACOR Failure

CACOR has a number of subprocesses associated with it. When CACOR terminates, so do these subprocesses. In the event of abnormal CACOR termination it may be necessary to terminate these processes yourself. Therefore, in the event of a serious CACOR problem, you should do the following:



Before you exit from CACOR, you need to exit from CAOBS:

 Exit CAOBS:  You must exit CAOBS before restarting CACOR.  
 CAOBS$>$ exit     
If CAOBS doesn't respond to prompting, use ctrl-C.
(Actually,the order of exiting is not particularly important, however you must have exited from CAOBS before you attempt to restart CACOR.)


To exit CACOR:

 Type ctrl-C in the xterm it was started from.     
 CHECK: for old processes associated with CACOR: e.g., CORDAT, XFER, or CONFIG.     
 CACCC$>$ ps -fade     
       
 Kill these old processes with:     
 CACCC$>$ kill [process id]

Restart CACOR, then CAOBS:

    
 CACCC$>$ cacor     
 XBONES$>$ caobs     

You cannot start observing until both are running.

Note that CACOR recalls the last correlator configuration after a restart. That is, you do not need to reprogram the correlator if CACOR crashes. You should, however, check that the correct configuration has been recalled (look at the Configuration field on the CACOR screen).

You may also want to check that the variables (which represent data display buffers and are required by VIS in order to display visibilities) have been recalled, though this is not usually necessary. Retrieve a new variable set if you are unsure.


next up previous contents index
Next: CACOR: Integration Cycles Missed Up: Troubleshooting Previous: Delay Unit Control Computer:   Contents   Index
Robin Wark 2006-10-24