Troubleshooting and temporary procedures

The following sections list the solutions to the most common problems encountered by users, including indications on how to deal with present bugs or inefficiencies in the system. The records are sorted according to the main operation areas in which the problems arise.


Users are advised to read these “hints” at the beginning of the session and before attempting (possibly unnecessary) heavy-handed operations on the system.



  • The Scheduler panel shows a FAILURE flag.

Due to a system bug, such flag might not indicate an actual problem. Usually, when the FAILURE status is fake, the launch of a new schedule resets it. If you are already running a schedule, stop it and re-launch it from the scan_subscan that was next due.

If you are performing the initial setup, get to the point of launching a schedule and check whether the flag resets to OK. Pay then attention to the fact that new acquisitions are correctly recorded (i.e. verify the presence of new FITS files, using the quick-look tools or checking the updates in the output data folder). If the FAILURE status persists and observations do not proceed correctly, call for assistance.


  • After a setup, the antenna slews to an unwanted position, even though I have never commanded any pointing

This depends on the Antenna Control Unit (ACU) behavior: the ACU, after a setup, always commands the antenna to go to the last pointed position. This is very inconvenient, and DISCOS cannot directly stop it at the moment. You may immediately stop the slewing by commanding, right after the setup, a properly nearby position using goTo=[Az’d’,El’d’] so that, while you complete your setup procedures, the dish stops very near the present position. If the antenna is, for example, unstowing, the commanded position could be goTo=180d,80d as it is very near the 180d,90d stow position.


  • The initial setup fails, but it is difficult to assess what goes wrong.

Instead of using the overall setup commands, give in the operatorInput the individual commands which deal with the different sub-systems, so that it is easier to identify the misbehaving element.

For example, the setupKKC command can be substituted by (the actual receiversMode code to be used depends on the desired setup):

> antennaSetup=KKC
> receiversSetup=KKC
> initialize=KKC
> device=0
> calOff

For other receivers, the codes of course vary.



  • I’ve performed cross-scans in order to fine-tune the pointing, but the measured offsets are not actually applied to the following acquisitions

System offsets, such as the ones measured with a Point acquisition, sum up to the ones indicated inside schedules ONLY if they are expressed in the same coordinate frame. This means that, if you perform observations using EQ offsets, also the fine-pointing cross-scans must be carried out in the EQ frame. The same holds for HOR scans. If there is a frame mismatch, the system offsets are automatically rejected (this bug is under fixing).


  • I’ve stopped an XARCOS schedule and no further operation is accepted by the system.

Always stop your schedules with:

> haltSchedule

when you are using XARCOS; otherwise it will keep a busy status and the next operations will become impossible to perform.


  • I’ve launched a surely correct schedule, but parts of the system crashed.

Pay attention to the syntax, you might have inserted unwanted characters like an extra “ / ”: the startSchedule command must be given as:

> startSchedule=[schedname].scd,[N]

IMPORTANT: the projectID written inside the .scd schedule file MUST coincide with the project in use, otherwise an error will rise and the schedule will not be launched.


  • Dead time between consecutive subscans is much longer than expected

Are your schedules very old? It is now necessary to delete from old schedules all the post-scan wait times, as the system takes automatically care of computing and applying proper delays according to the deceleration ramps duration. If you specify a wait time in your post-scan procedures, it will add to the system-computed delays.

Quick-look tools


  • The calibrationtoolclient does not open

In order for the client to start, the CalibrationTool writer must be active. So, you either wait for it to be active while the schedule runs, and then you timely start the client by giving the proper command in a terminal shell, or you open it before launching any schedule and explicitly invoking the CalibrationTool using the command chooseRecorder=MANAGEMENT/CalibrationTool in the operatorInput panel, then starting the client in the terminal shell.


  • The web-based quick-look is not showing XARCOS data

This is a known bug, presently under fixing. The old IDL tools are not available anymore, so at the moment there is no option to visually inspect XARCOS data in realtime.