When a new connection to the control program has been established, the controller starts up the rest of the tasks in the control system, and passes them the initialized resource objects that it allocated for them. If any of these tasks subsequently reports a fatal error or becomes unresponsive to periodic probes from the controller task, then the controller reboots the control system.
If the connection to the control program is subsequently lost, the controller shuts down the other control-system tasks, re-initializes their resource objects, then goes back to the previously described loop in which it tries to re-contact the control program.
While the control system is active, the main responsibility of the controller task is to act as a communications gateway between the external Sun control program and the real-time control system.
On receiving a network message from the control program, the controller task unpacks the message and forwards its contents to whichever task is responsible for interpretting it. It doesn't wait for a reply.
In the other direction, the control program forwards status
messages from control-system tasks to the control program to be
logged. To take advantage of this the other tasks report status
messages simply by calling a plug-in replacement for
fprintf() called lprintf().
The controller also forwards job completion messages from other
tasks to the scheduler and astrometry tasks in the control
program. These messages are used in the implementation of the
acquired()
scheduling function.
In order to allow for the limited bandwidth of the connection to the control program, and to accomodate the lack of real-time timing guarantees in the control program, the scanner maintains a circular network buffer of up to 100 snapshots. If the system timing generator is configured to interrupt the scanner faster than snapshots can be transfered to the control program, then this circular buffer eventually fills up. If this happens the scanner stops adding frames to the circular buffer until the buffer has completely drained. This tactic guarantees that the control program receives at least 100 contiguous frames between gaps. This is a useful feature for high-speed monitoring.
The tracker task has the responsibility of steering the telescope and providing the time reference of the control system. To obtain time, it controls a time-code reader VME card, which in turn gets its time reference from a GPS receiver. To control the telescope drives the tracker task talks to a PMAC motion controller VME board. This contains a motion control program designed by Steve Padin specifically for the CBI drive system. Every second, on the receipt of an interrupt from the time-code reader, the tracker task uses the current telescope model to compute the encoder positions and velocities that the PMAC should attain on the following 1-second tick, and passes these numbers to the PMAC. The PMAC interpolates between these one-second points for each telescope axis to generate a smooth trajectory for the telescope. For this scheme to work, both the PMAC and the tracker task have to synchronize their internal clocks with GPS. To this end the PMAC uses an 8KHz signal generated by the time-code reader as its clock, and at pertinent times the tracker task tells the time-code reader to generate a pulse that will be seen by the PMAC at a prearranged time.
The weather task receives 30 second updates of weather statistics from an external weather station. This includes the outside temperature, wind-speed, wind-direction, atmospheric pressure, relative humidity and internal weather-station diagnostics. These values are received from the weather station as binary records transmitted over an 8-bit-clean serial line. On receipt the values are recorded in the local database for subsequent archival by the scanner task, and if more than five minutes have passed since the last refraction calculation has been performed, they are used to compute new atmospheric refraction parameters which are then sent to the tracker task.
The receiver controller task is responsible for the control functions of the 13 receiver cards. This includes controlling heaters, phase-shifter motors and a number of local oscillator stages.
Control of the phase-shifter motors requires special attention. To give schedule writers the option of waiting for the phase-shifter motors to reach their commanded positions, the receiver control task has to monitor the state of the motors and then send a completion message to the control program. The two motor acquisition registers of each of the commanded receivers thus have to be polled at the end of each hardware integration, either until they report successful completion, or the operation times out (after 10 seconds). At this point the completion message is sent to the control program. This is accompanied by an error message if the operation timed out. Receiver cards that have been marked as unreachable by any task, are ignored by the receiver control task. Thus it will continue to function normally in the absence of any of the receiver cards.
If a new phase-shift position is requested while waiting for a previous one, the receiver control task immediately starts on the new one, and stops checking for completion of the previous move.
Currently the NoiseCal task controls a power meter via the GPIB
task. This meter is used to measure the power generated by the
noise calibration source that is used to interpolate between
absolute source calibration measurements. The power meter is read
and zeroed at intervals that are user settable via the
noise_cal_interval scheduling command.
The GPIB task assumes the responsibility of being the active controller of a GPIB instrument bus, via a VME interface card. Currently the only instrument attached to this bus is the meter that is used to measure the power being generated by the noise-calibration source.
After configuring the GPIB bus, the task accepts requests from other tasks to read messages and write commands to specified GPIB devices. Completion statuses and messages read from GPIB devices are passed back to the requesting task via callback functions. These callbacks generally submit the response on the message queue of the originating task.